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This third edition continues to be based on CCITT Recommendation X.25 as published in 
the "Yellow Book’ instead of the ‘Red Book' version, adopted by the VIIIth Plenary 
Assembly in 1984. Text in Part I that differs from that in the previous edition is 
tdentified by vertical bars in the left margin of this edition. 


The information contained in this manual may be updated periodically; before using 
this publication in connection with the operation of IBM systems or equipment, consult 
pak acg IBM System or Processor Bibliography for the editions that are current and 
applicable. 


PART II of this edition is expanded to include detailed specification of the 
protocols, formats and procedures for the Enhanced Logical Link Control CELLC) offered 
by some IBM SNA X.25 DTEs for use on SNA-to-SNA connections, as well as those employed 
by some IBM SNA X.25 DTEs on SNA-to-SNA and SNA-to-Non_SNA connections. 


Material presented itn this manual may contain reference to, or information about, IBM 
products (machines or programs), or services that are not announced in some countries. 
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A form for readers’ comments is provided at the back of this publication. If the form 
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P. O. Box 12195, Research Triangle Park, North Carolina, U.S.A. 27709. IBM may use or 
distribute any of the information you supply in any way it believes appropriate 
without incurring any obligation whatever. You may, of course, continue to use the 
information you supply. 


Portions of CCITT Recommendation X.25 (Geneva, November 1980) from the CCITT Seventh 
Plenary Assembly YELLOW BOOK Volume VIII - Fascicle VIII.2 are reprinted in this 


manual with special authorization of the International Telecommunications Union 
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PREFACE 


This manual describes the elements, including optional user facilities, of CCITT 
Recommendation X.25 - INTERFACE BETWEEN DATA TERMINAL EQUIPMENT CDTE) AND DATA CIRCUIT 
TERMINATING EQUIPMENT CDCE) FOR TERMINALS OPERATING IN THE PACKET MODE ON PUBLIC DATA 
NETWORKS (Geneva, 1976; amended Geneva, 1980) - that are applicable to IBM SNA network 
nodes that can attach to X.25-based Packet-Switched Data Networks (PSDNs) 


Note: This third edition continues to be based on CCITT Recommendation X.25 as 


published tn the ‘Yellow Book’ instead of the ‘Red Book’ version, adepted by the 
VIIIth Plenary Assembly in 1984. 


Excerpts from CCITT Recommendation X.25 (Geneva, November 1980), including sections 
1.1 - 1.2, 2.1 - 2.4 Cexcept LAP procedures), 3.1 - 3.5, 4.1 - 4.6, 6.1 - 6.53, 
6.5 - 6.8, 7.1 - 7.2, 7.4% Cexcept Datagrams), Annex A Cexcept Datagrams}, Annex B, 
Annex C, Annex D and Annex E are reprinted in this manual. 


IBM SNA data terminal equipment CDTEs) that use the X.25 recommendation to interface 
to PSDN data circuit-terminating equipment (DCEs) are referred to in this document as 
IBM SNA X.25 DTEs. Elements of CCITT Recommendation X.25 (1980) are selected by IBM to 
support two basic categories of connections: 


a. SNA-to-SNA: 


connections between SNA X.25 DTEs, via virtual calls or permanent virtual 
circuits, or both, ar2 accommodated through intervening packet-ssetrtched data 
network(s). 


b. SNA-to-non_SNA: 


connections between SNA X.25 DTEs and non-SNA X.25 DTEs, via virtual calls or 
permanent virtual circuits, or both, are accommodated through intervening 
packet-switched data network(s). 


The DTE/DCE interfaces for SNA-to-SNA connections and SNA-to-non_SNA connections 
differ only at the packet level; therefore, the definitions and descriptions of the 
physical level and the link level apply equally to both types of connections. 


Information itn this manual must not be construed as describing any specific IBM 
product (machine or program) or service. Neither can it be construed to mean that all 
or any specific IBM products necessarily provide only, or all of, the X.25 DTE/DCE 
interface functions described herein. 


In ‘addition, note that the ELLC, QLLC and PSH Protocols defined in this manual 
describe existing implementations of end-to-end control functions that are required 
above the X.25 DTE/DCE Interface. Further end-to-end controls applicable fer use with 
X.25-based network services may be implemented as requirements become more clearly 
identified. Readers are cautioned to refer to appropriate IBM product description and 
operation manuals for information regarding the availability and characteristics of 
X.25 DTE/DCE interface functions supported by specific IBM products. 


The reader is assumed to be conversant with both CCITT Recommendation X.25 and SNA. A 
list of applicable references is included, at the end of part I, to help the less 
informed reader to understand these subjects. 
This manual is composed of two parts: 

PART I - contains an overview of the relationship between SNA and X.25; and, 

PART II - is patterned after excerpts from CCITT Recommendation X.25 (Geneva, 


povenpee 1980) with modifications identified as noted in the introduction to Part 
TL. : 
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PART tf 


This part presents an overview of the relationships that exist between SNA and X.25 
composed of: | 


Chapter 1, “INTRODUCTION,” which briefly describes the evolution of CCITT 
Recommendation X.25, IBM's statement of direction relative to its support and the 
evolution of IBM's support 


Chapter 2, "ARCHITECTURAL CONSIDERATIONS," which states the architectural 
relationships between SNA and X.25; it also states the SNA assumptions upon which 
IBM X.25 support is predicated. | 


Chapter 3, "X.25 ELEMENTS IN IBM SNA X.25 DTEs,”" which describes the basic 
elements of CCITT Recommendation X.25 selected by IBM for SNA-to-SNA connections 
and for SNA-to-non_SNA connections using virtual circuit services provided by 
X.25-based PSDNs. | 


Chapter 4, "OTHER SYSTEM CONSIDERATIONS," which briefly describes security, 


reliability, availability and serviceability as they relate to the operation of 
SNA in PSDN environments. 
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SNA/X.25 DTE/DCE Interface 


1.0 INTRODUCTION 


Maturing packet-switching technology continues to gain acceptance among 
Telecommunications Administrations, as well as information processing communities, 
throughout the world during the nineteen-eighties. Packet-~switched data network 
services are now available for public use in numerous countries and several such 
networks are being operated for private use by corporate enterprises and government 
agencies. PSDNs are currently being installed in both the public and private sectors 
acune the world and still others are being planned to begin operations within the 
ecade. 


1.1 EVOLUTION OF THE X.25 DTE/DCE INTERFACE 


The International Telegraph and Telephone Consultative Committee (CCITT) has 
developed Recommendation X.25 to facilitate attachment of customer data terminal 
equipment to public PSDNs. It was first adopted® at the CCITT VIIth Plenary Assembly 
in 1976 to provide a "standard" interface between customer-provided data terminal 
equipment (CDTE) and public PSDN data circuit-terminating equipment (DCE) Ccommonly 
referred to as the X.25 DTE/DCE interface). 


In 1978, updates contained in a provisional recommendation? were approved by the 
CCITT. A revised version? incorporates additional enhancements approved by the CCITT 
plenary assembly at Geneva in November of 1980 


Numerous Telecommunications Administrations, Recognized Private Operating Agencies 
CRPOAs) and Common Carriers have either implemented, or published plans to implement, 
PSDNs with DTE/DCE interfaces based on CCITT Recommendation X.25. Some of these are 
summarized in Table I-1 based on information publicly available as of December 1984. 
Several private PSDNs have also adopted versions of the X.25 DTE/DCE interface as a 
method of attachment. 


Increasing numbers of users of public and private PSDNs specify DTEs that are capable 
of attaching via X.25 DTE/DCE interfaces. They desire vendor-independent, common 
attachment interfaces such that DTEs of one vendor can communicate effectively with 
DTEs of other vendors through public or private PSDNs, or both. 


Elements of the X.25 DTE/DCE interface can help to meet the former requirement. They 
enable DTEs to connect to PSDNs, to establish connectivity to other DTEs through one 
or more PSDNs and to transfer data packets from one DTE to the other. While such 
connectivity is essential to effective communication, it cannot be assumed that simply 
because two devices can connect to a PSDN via the X.25 DIE/DCE interface that they can 
communicate with each other in any useful way. 


Effective communication between DTEs requires additional protocols at one or more 
levels above the packet level of the X.25 DTE/DCE interface. Efforts are currently 
being made within the standards community to develop a standard networking protocol, 
referred to as Qpen Systems Interconnection (0SI), to meet the needs of such higher 
levels. These efforts are taking place within the International Organization for 
Standardization (IS50)*, the International Telephone and Telegraph Consultative 
Committee (CCCITT)*, the European Computer Manufacturers Association (CECMA)>, the 
Institute of Electrical and Electronic Engineers (IEEE)* and various’ other 
organizations. 


The ISQ has published a Basic Reference Model for OSI*. The protocols that allow 
effective communication between diverse IBM SNA X.25 DTEs such as data processing, 
distributed computing and office systems are provided by the highér levels of SNA. 
Reference 15 describes some relationships that exist between SNA?2*,27%,274,25,2° and the 
ISQ Basic Reference Model for OSI*. Analyses®,’,*7,79° have shown that pa "25 DTE/DCE 
interfaces specified for various public and private PSDNs generally differ to some 
extent. Such differences have been attributed to differing implementation time frames 
or interpretations of the Recommendation, or both. Such diversity has been recognized 
by the Common Carriers, Administrations and Recognized Private Operating Agencies 
CRPOAS). Efforts by some of these organizations to minimize such differences by 
generally agreeing to implement a less permissive X.25 Recommendation!,’7,!°,2! has, 
thus far, met with limited success. Thus, it can be anticipated that, as X.25 
continues to evolve, network specific differences in interface definition will 
probably continue for the foreseeable future. 
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CCITT Recommendation X.25 has continued to evolve during the 1980-1984 plenary period 
and additional functional capabilities have been adopted. IBM anticipates, however, 
that such additional capabilities will not impair the operation of DTE implementations 
based on the version of CCITT Recommendation X.25 adopted by the VIIth Plenary 
Assembly at Geneva in November 1980 and published in the "Yellow Book' and that are 
reflected in this manual. Additional capabilities adopted for CCITT Recommendation 
X.25 by the VIIIth Plenary Assembly are being evaluated to ascertain their 
applicability to DTEs in SNA environments and decisions regarding support of such 
additional capabilities will be based on future business and technical considerations. 


Tabie I-l1: Some Plans and Implementations for Networks offering 
X.25 Interfaces 


Country Network Availability 
ARGENTINA. = = eS SSS ARE AG, =e ere = 1983 
RUSURALLIA: “SS = eee AUSIEAC. SSS SS 1983 
RUDIRTA. oS Se SS ERINE( = Set Ss Ses 1982 
DECGLUM: =o eo = DOS: ES ee ee 1982 
BRAZIL SS = Se So RENPACG... ees eS Se 1984 
CANAUR SS SSS Se DATAPAC --- 7-7-7 > 1977 

INFOGRAM -~----7-- 1982 

CHILE, Ss SS CECOM). SS Se 1981 
DENMARK: = = SoS St DATACAK:. === 1983 
EUROPE Sem See a ee oe ee EUVRONE, =e = 1979 
FINCAND. (= Se = DATARAR. SS SS = 1983 
ERAN CE (ce se: Saas Ser ee ee eee TRANSPAC -- 7-7-7 7-7 1978 
GERMANY SSS SS DATEASR (SS Se 1981 
HONG KONG. === eS = CUNEL:.. <== ===> * 1984 
DATAPAC. = = SSS Se 1984 

THDONESIA SS = eS = PACKSATNET ------ 1984 
TRELAND: 7S ae ELREACG SS ES ee 1984 
PSRAGL. SS ee ee a ee PRINGD Sk sae 1982 
LAL SS eS Se ee LtAP AG SS eres eee 1984 
VAPAN, 2 SS = Se DOX-f SE ere —-—- 1980 
VENUS... ee See 1982 

KOREA, re ee re se DACOM-NET -~ - ----- 1984 
RUXEMNBURG: ry ei LUXPACG. (SSS Se 1983 
MALAYSIA 9 = = SSS SSS MAYRAC SSS SSeS 1984 
MEX TCO. Sess eee ie i ee TELEPAG. 230 i Se oe ee 1982 
NETHERLANDS === => == DATANE T=) eS 1981 
NEW ZEALAND -~--~-~--->- PSN ee eee eee ae ce 198% 
NORWAY = SS "See eee DATAPAK -~-~-~-~~—-— 1983 
FURIUGAL = Se = PRINEC. (‘eS e= = 198% 
SINGAPORE = SSeS “SELEERG. SS eS Se, Le 
SOUTH AFRICA - ------ SAPONEL == eS ee 1982 
Seal. Ser SS SS Sa CINEXCS:.. 2° Se 1982 
SWEDEN SS SS ee DATAPAK ---7-7- 7-7 1984 
SWITZERLAND ------ > TELEPAG SSS SS 1983 
VAIWEN 3. = oe PACKED = SS = 1984 
UNITED KINGDOM - - - - -— — PACK] 30.0 SSS Se 1981 
UNITED STATES of AMERICA — ACCUNET ------ >= 1983 
TELENED Soe ee Se 21960 

| DYING) 2 ee 1980 

YUGOSLAVIA == = >= - > > JUGOPAK ---7--7- > a —- 1985 


This table is an illustrative reference only. It reflects some of the 


information publicly available as of December 1984 which will doubt— 
less change as X.25 network plans mature and implementations progress. 


1.2 IBM STATEMENT OF DIRECTION 


In May of 1980 IBM made the following public announcement about its use of CCITT 
Recommendations X.21 and X.25: 


"IBM encourages the use of international standards as the basis for interfaces to 
public data networks providing circuit-switched, packet-switched and leased-circuit 
services. IBM continues to participate in and contribute to international standards 
efforts to develop and enhance these interfaces. Services with interfaces based on 
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CCITT Recommendations X.21 and X.25 provide users with new alternatives’ for 
transmission that supplement the functions provided by IBM's Systems Network 
Architecture (SNA), and should be made available to IBM's customers. 


"It i products to public data networks with X.21 and X.25 interfaces. For example, in 
accordance with IBM's 1978 statement of Direction regarding X.21, IBM announced in 
December 1979 the capability of attaching certain SNA products to Nippon Telegraph and 
Telephone's leased-circuit and circuit-switched X.21l-based services in Japan. IBM has 
also released product adaptations that permit certain products to utilize X.25-based 
services in Canada, France, the Federal Republic of Germany and the Netherlands!7,?§&, 
[The first of these X.25 product adaptations was announced in 1977.] 


"Announcement of attachment capability supporting additional products or functions, 
or for other public data networks with X.21 or X.25 interfaces, will be based on IBM's 
technical and business judgement in addressing the requirements of its customers." 


1.3. EVOLUTION OF IBM X.21 AND X.25 INTERFACES 


In 1980, an X.21 general information manual was published'*. It describes the CCITT 
Recommendation X.21 interface to public data networks (PDNs) as implemented in data 
terminal equipment by IBM. Included are: 


e A brief overview of CCITT Recommendation X.2l 


° Information on the functional, mechanical, and electrical characteristics 
specified in CCITT Recommendation X.21 . 


e Information on the operation of both the circuit-switched and leased-circuit 
network service interfaces defined in CCITT Recommendation X.21. 


IBM also announced in 1980, for certain products, support of X.21 circuit-switched 
services in Denmark, Finland, Norway and Sweden. 


Since May of 1980 IBM has announced X.25 capability for numerous products to attach to 
many different PSDN's around the world. 


CCITT Recommendation X.25 defines three levels of the DITE/DCE interface that PSDNs use 
as a design guide for X.25-based services: 


1. Physical Level -—- the mechanical, electrical, functional and procedural 
characteristics to activate, maintain and deactivate the physical link between the 
DTE and the DCE. 


2. Link Level — the link access procedure for the interchange of data across the link 
between the DTE and the DCE. 


3. Packet Level - the packet format and control procedures for the exchange of 
packets containing control information and user data between the DTE and the DCE. 


CCITT Recommendation X.25 describes the three levels and the range of services that 
may be provided by PSDNs from the perspective of the DCE. This manual provides 
information on the three levels of CCITT Recommendation X.25 (1980) and describes 
architectural and design choices made by IBM to meet the requirements of its 
customers from the perspective of IBM SNA X.25 DTEs. 


The services, functions, facilities, and parameter ranges described herein for IBM SNA 
X.25 DTE’s are based on reference 1, the revised X.25 Recommendation approved by the 
CCITT plenary assembly at Geneva in November, 1980. 


This X.25 general information manual expounds further on IBM's use of elements of X.25 
at all three levels. It addresses only those elements required to support connections 
between IBM SNA X.25 DTE's and other X.25 DTE's CSNA or non-SNA) using virtual call and 
permanent virtual circuit services provided by PSDNs. It does not address direct 
DTE-to-DTE connections without an intervening PSDN; nor does it address IBM SNA X.25 
nodes functioning as DCEs. 


IBM support of other X.25-related recommendations, such as packet 
assembly/disassembly (PAD) functions®,!%, are beyond the scope of this manual. 


INTRODUCTION . | I=3 


SNA/X.25 DTE/DCE Interface 


2.0 ARCHITECTURAL CONSIDERATIONS 


Packet-switched data network services can provide an efficient and economical method 
for transporting information in some instances. However, application requirements, 
geographical considerations and applicable tariffs often dictate the use of other 
services and facilities for transporting information. Virtual circuit (VCs) are, 
therefore, integrated into SNA so as not to preclude concurrent use of other services 
and. facilities offered by Communication Carriers, Telecommunications Administrations 
and Recognized Private Operating Agencies (RPOAS) around the world. 


Because of the pervasiveness of X.25 DTE/DCE interfaces, IBM encourages common 
interpretation and implementation to the fullest extent possible. This document 
advances this goal by describing the elements deemed necessary to support two basic 
categories of connections: 


o SNA-to-SNA Connections that allow IBM SNA X.25 DTEs to be connected to each 
other via virtual call or permanent virtual circuit services, or both; and, 


e SNA-to-non_SNA Connections that allow IBM SNA X.25 DTEs to be connected to 
non-SNA DTEs via virtual call or permanent virtual circuit services, or both. 


It describes architectural directions for both categories of connections but focuses 
primarily on the elements of CCITT Recommendation X.25 (1980) required to support 
SNA-to-SNA connections. 


2.1 SNA-TO-SNA CONNECTIONS 


One objective of Systems Network Architecture is to afford users the broadest possible 
range of telecommunications services and facilities to meet their requirements. 
Figure 1 depicts some of the data transmission services and facilities available to 
SNA customers in various parts of the world. 
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¥ — This DLC (Data Link Control) contains Logical Link Control (LLC) and Virtual 
Circuit Protocol (VCP) components, described in the text. 


Figure 1. Coexistence of Data Transmission Services and Facilities: within SNA 
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Computer network architectures, in general, provide for the interconnection of 
physically distributed functions via various types of data transmission facilities. 
Such directly connected nodes are termed ‘adjacent’ within SNA. The Data Link Control 
sae elements provide the protocols used to transfer information between adjacent SNA 
nodes. 


Some SNA nodes, such as clusters and terminals!?®, attach to only one adjacent SNA node 
via a single real Link. Such single-link nodes are treated as single-virtual-circuit 
X.25 nodes as shown in Figure 2 on page I-6. SNA nodes that can connect to multiple 
SNA adjacent nodes over different physical links, or multi-drop links, are treated as 
multiple point-to-point virtual-circuit connections as shown in Figure 3 an page I-7. 
In the multi-access configuration, SNA nodes have the capability of cennecting to 
multiple SNA adjacent nodes using multiple virtual circuits via one or more X.25 
DTE/DCE interfaces. 


SNA nodes interconnected by virtual circuit services remain logically adjacent and the 
X.25 virtual circuit protocol (VCP) provides the mechanism to transfer information 
between these adjacent network nodes. Therefore, virtual circuits serve similar 
functions in the system as other data transmission services and facilities and 
naturally appear at the same architectural level. 


This natural structure provides for the coexistence of the various data transmission 
services and facilities, as well as a desirable multiplexing capability. For example, 
all traffic flowing between adjacent network nodes is readily multiplexed onto a 
single facility. 


To permit concurrent use of data link control and virtual circuit protocol services, 
all of the properties of the former must be available in the latter. IBM SNA X.25 DTEs 
employ Logical Link Control CLLC) protocols to provide certain adjacent node services 
and optionally, to enhance the quality of service exhibited by underlying network 
services, in environments where SNA nodes are connected through one or more PSDNs. 
These protocols are known as QLLC, which uses ‘Qualified’ data packets to transfer 
data link control information between the two SNA nodes, and ELLC which employs LLC 
headers carried in the user data field of data packets to provide optional circuit 
assurance and data integrity capabilities. Once data link connectivity has been 
established, SNA Path Information Units (PIUs)?*> are transferred in normal, 
unqualified data packets. PIUs that exceed the maximum user data area of the data 
cee are transferred as packet sequences concatenated by the More Data Mark ('M! 
bit). 


Note: Some initial IBM SNA X.25 DTE implementations do not support the QLLC, ELLC and 
fa bit procedures. They perform adjacent node services and 
segmentation/concatenation using a Physical Services Header (PSH)*%. All IBM SNA X.25 
DTES may not support the Enhanced Logical Link Control CELLC) procedures. 


It is not an objective to restrict any actual implementations of the X.25 DTE/DCE 
interface functions within IBM products to the elements described here. Network 
specific options may impose additional requirements that must be met to make specific 
IBM SNA X.25 DTEs viable in some countries. Decisions to support national options are 
intra ia technical and business considerations that are beyond the scope of this 
maructl. 
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Figure 2. Real Links Become X.25 Virtual Circuits: 
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Figure 3. X.25 Multi-Access: for SNA-to-SNA Connections 


2.2 SNA-TO-NON SNA CONNECTIONS 


SNA-to-non_SNA connections provide a mechanism for the exchange of data between an 
application program that resides ‘in an SNA node and a remote non-SNA terminal. For 
example, remote non-SNA terminals can be non-SNA X.25 DTEs or start/stop terminals 
attached to a packet assembly/disassembly (PAD) PSDN facility as defined by CCITT 
Recommendations X.3, X*.28 and X.29. Three types of operation defined for 
SNA-to-non_SNA connections are mapped, transparent and hybrid. No standard protocol 
is assumed above the packet level of CCITT Recommendation X.25 for SNA-to-non_SNA 
connections. Higher level protocols remain a matter to be agreed upon between the 
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individual non-SNA terminal and the supporting application program within the SNA 
network. | | 


2.2.1 Mapped Operation 


Mapped operation allows X.25 packet level protocols to be mapped to and from similar 
SNA protocol subsets directly at the SNA X.25 DTE/DCE interface. Thus, virtual 
circuits can be mapped to SNA sessions, ona one for one basis, as depicted in Figure 4 
on page I-93. A host application program can communicate with the non-SNA without any 
X.25 sensitivity. However, the application and the remote node must each understand 
the data streams being exchanged and process them accordingly. 


Aa 


2.2c.ec Transparent Operation 


In transparent operation, X.25 packet level protocols can be implemented in an 
application program (Coutside the structure of SNA). In this case, the X.25 packet 
level protocols are transported, transparently, within SNA between the application 
yirtuel ae the X. 25 DTE“DCE interface and SNA sessions can support one or more 
virtual calls. 


2.2.3 Hybrid Operation 


In hybrid operation, X.25 packet level protocols are neither fully mapped nor fully 
transparent. A host application program may perform some X.25 packet level functions 
as tn transparent operation while the remaining X.25 packet level functions are 
performed at the SNA Xx. 25 interface. 
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Note: Non-X.25 DTEs may be supported by PSDN PAD functions as defined by 
CCITT Recommendations X.3, X.28 and X.29. 


Figure 4. One-to-One Session Mapping to Virtual Circuits: for SNA-to-non_SNA 
Connections 


2.3 MULTIPLE DTE/DCE INTERFACES 


Some IBM SNA X.25 DTEs can support multiple X.25 DTE/DCE interfaces. To do so is a 
product-specific choice based on traffic requirements and the need to directly access 
two or more networks concurrently. | 


Some optional user facilities (e.g., modulo 128 packet sequence numbering) require an 
X.25 DTE/DCE interface that is separate from the interface that supports the normal 
facility (e.g., modulo 8 packet sequence numbering). 

Each X.25 DTE/DCE interface is assumed to correspond to a unique address agreed upon 
with the network Administration. 
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3.0 X.25 ELEMENTS IN IBM SNA X.25 DTES 


The elements of CCITT Recommendation X.25! selected for use in IBM SNA X.25 DTEs are 
described in this section. Physical level, link level and packet level interfaces are 
addressed. End-to-end protocols that reside at one or more levels above the packet 
level are not described. | 


SNA-to-SNA and SNA-to-non_SNA connections differ only at the packet level. Therefore, 
descriptions of the physical level and the link level are common to both types of 
connections. , 


Tables contained in subsequent sections use the following terminology: 
All - for functions provided by all IBM SNA X.25 DTEs. 


Some - for functions that may be provided by selected IBM SNA X.25 DTEs to meet. 
specific functional requirements and marketing objectives. 


None - for functions normally not provided by IBM SNA X.25 DTEs. 


3.1 PHYSICAL LEVEL 


A summary of IBM SNA X.25 DTE physical level characteristics is provided itn Table I-2. 
During an interim period, described in reference 1, IBM SNA X.25 DTEs use CCITT 
Recommendation X.21_bis® for non-switched circuits. However, some IBM SNA X.25 DTEs 
also support the X.21 interface!?,!%,!% for non-switched circuits; it will become the 
primary support at the end of the interim period. 


At speeds of 19.2 kilobits per second (kbit/s) and below, IBM X.21_bis implementations 

conform to CCITT Recommendation V.24!! with V.28!! electrical characteristics. At 

signaling speeds in excess of 19.2 kbit/s, IBM X.21_bis implementations conform to 

~ CCITT Recommendation V.351!1. Some products may provide other non-X.21 interfaces as 
required for attachment to specific network services. 


All links operate duplex (two-way simultaneous) at one or more of the X.25 speeds 
listed in Table I-2. The particular speed or speeds supported by IBM SNA X.25 DTEs is 
product specific. Some IBM SNA X.25 DTEs may also support one or more of the 
additional speeds shown in Table I-2. X.21 switched and X.21_bis switched are not 
used at the physical level of the X.25 DTE/DCE interface by IBM SNA X.25 DTEs. 


———_————_--— 
Table I-2: Summary of Physical IBM SNA 
Level Characteristics | X.25 DTEs 


X.21 Switched 

X.21_ bits Switched 
X.21 Non-Switched 
X.21_bis Non-Switched 


Duplex Transmission Facility 


X.25 Speeds — -4 kbit/s 
8 Li 


Additional Speeds 


* During the interim period, after which X.21 will be required 
and X.21_bis will be optional 
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3.2 LINK LEVEL 


CCITT Recommendation X.25 defines two link access procedures (LAP and LAPB) for the 
link level. IBM SNA X.25 DTEs use the balanced procedure, LAPB. The symmetrical 
procedure, LAP, is used only by certain early IBM DTE implementations but will not be 
used in new IBM SNA X.25 DTE implementations. 


The IBM SNA X.25 DTE link level is required to be compatible with the DCE link level as 
defined in reference 1. Thus, certain choices and clarifications of the balanced 
procedure are required for DTEs. These are given, for IBM SNA X.25 DTEs, below: 


1. The information field of all I-frames transferred across the DTE/DCE Interface 
must contain an integral number of octets Ceight-bit bytes). 


2. IBM SNA X.25 DTEs do not generate the Idle Channel State as a normal sequence. 


3. IBM SNA X.25 DTEs detect but do not, necessarily, consider the Idle Channel State 
to be an error condition; they may assume that the DCE has temporarily suspended 
transmission. 


G4. IBM SNA X.25 DTEs support modulo '8' sequence numbering; modulo '128" sequence 
numbering 1s not used at the link level, since this option is not provided fpr by 
CCITT Recommendation X.25 (Geneva; November 1980)!. 


5. IBM SNA X.25 DTEs that implement supervisory and unnumbered commands transmit all 
such commands with the poll (P) bit set to one. 


6. Upon receipt of a command frame with the poll bit set to one, IBM SNA X.25 DTEs set 
the final (CF) bit to one in the next response frame transmitted. 


7. Exceptional conditions may be reported by IBM SNA X.25 DTEs to the DCE using the 
FRAME REJECT CFRMR) response as defined in reference 1. They maintain the frame 
rejection condition until it is reset by the DCE or until higher level DTE 
recovery 185 initiated locally. 


8. IBM SNA X.25 DTEs, upon receipt of a FRMR response, are responsible for returning 
the link to operational mode by initiating a link resetting procedure. However, 
to assure synchronization, initiation of the link resetting procedure may be 
preceded by a link disconnection procedure. 


9. After receiving a RECEIVE NOT READY CRNR) frame, IBM SNA X.25 DTEs wait until 
receipt of a RECEIVE READY (CRR) or REJECT CREJ) frame before transmitting 
additional information (I) frames unless or until the link resetting procedure is 
completed. During this period of time, they will send an RR or RNR command frame 
in order to ascertain the status of the DCE 


10. Information (I) frames contain only one packet each. 
11. IBM SNA X.25 DTEs may employ a nested time-out function to avoid prematurely 


declaring link/stations inoperative because of transient errors on the 
transmission link. 


3.3 PACKET LEVEL 


The packet level elements are considered for two categories of connections via PSDNs, 
SNA~to-SNA and SNA-to-non_SNA. 


3-3-1 SNA-tO-SNA Connections 


The IBM SNA X.25 DTE packet level is required to be compatible with the DCE packet 
level as defined in reference 1. This section gives the packet level elements 
required for SNA-to-SNA communication, and defines how IBM SNA X.25 DTFEs use the 
packet level procedures, formats, and facilities in clarification of reference l. 


SNA-to-SNA communication 15 via virtual call (VC) or permanent virtual circuit (PVC) 


services, or both. Datagram services are not used. A given SNA X.25 DTE may contain 
virtual call capability or permanent virtual circujt capability, or both. Table I-3 
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lists the packet types used on SNA-to-SNA connections that affect given virtual calls 
CVC) and given permanent virtual circuits (PVC) and that affect all VCs and PVC at the 
X.25 DTE/DCE interface (I/F). Table I-4 lists the packet types that are not used on 
SNA-to-SNA connections. 


Table I-3: Packet Types Used by IBM SNA X.25 DTEs | X.25 
| on SNA-to-SNA Connections* SERVICE | 
PACKET TYPES —— 
ACCEPTED -—- INCOMING CALL 


CALL CONNECTED 

CLEAR INDICATION 

DCE CLEAR CONFIRMATION 
DCE DATA 

DCE RECEIVE READY 

DCE RECEIVE NOT READY 
RESET INDICATION 

DCE RESET CONFIRMATION 
RESTART INDICATION 

DCE RESTART CONFIRMATION 
DIAGNOSTIC . 


TRANSMITTED — CALL REQUEST 
CALL ACCEPTED 
CLEAR REQUEST 
DTE CLEAR CONFIRMATION 
DTE DATA 
DTE RECEIVE READY 
DTE RECEIVE NOT READY 
RESET REQUEST 
DTE RESET CONFIRMATION 
RESTART REQUEST 
DTE RESTART CONFIRMATION 


VC — Affects given Virtual Calls 
PVC — Affects given Permanent Virtual Circuits 
I/F — Affects all VCs and PVCs at the DTE/DCE Interface 


KK OK OK OOK 


mK KOK KEK OK OK OK OK mM KK OK KK OOK OK OK 
px pow 


* All packet types are not necessarily used by all IBM SNA X.25 DTEs 


Table I-4: Packet Types Not Used by IBM SNA X.25 DTEs 
on SNA-to—-SNA Connections 


PACKET TYPES 


NOT ACCEPTED -— DCE INTERRUPT 
DCE INTERRUPT CONFIRMATION 


DCE DATAGRAM 
DATAGRAM SERVICE SIGNAL 


NOT TRANSMITTED — DTE INTERRUPT 
DTE INTERRUPT CONFIRMATION 
DTE DATAGRAM 
DTE REJECT 


3.3.1.1 Initialization 


The packet level DTE/DCE interface is initialized before virtual call and permanent 
virtual circuit procedures begin. IBM SNA X.25 DTEs execute the DTE restart procedure 
after link level initialization is complete. The X.25 DTE/DCE interface becomes 
operational upon successful completion of the restart procedure. The restart 
procedure is used after normal link level activation and after link level failure 
recovery for packet level initialization. 
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3.3.1.2 Data Transfer 

Data is exchanged between IBM SNA X.25 DTEs using virtual calls or permanent virtual 
circuits, or both. IBM SNA X.25 DTEs may transmit: 

1. DTE DATA 

2. DTE RECEIVE READY and 

3. DTE RECEIVE NOT READY packets. 

They accept and respond to: 

1. DCE DATA 

2. DCE RECEIVE READY and 

3. DCE RECEIVE NOT READY packets. 


These packets are used as described in reference 1 except as noted in this section. 
DTE REJECT (CREJ) packets are not used. 


The characteristics of data packets used on SNA-to-SNA connections are summarized in’ 
Table I-5. 


Window Size = "1l' ¢ * "8" (Modulo '8') All 


Some 


Table I-5: Characteristics of Data Packets Exchanged IBM SNA 
on SNA-to-SNA Connections X.25 DTEs 
Qualifier Bit, "Q = 0° All 
"Q = 1! AlL1L*® 
Delivery Confirmation Bit, "D = 0° All 
'p .=1' None 
Packet Sequence Numbering, Modulo "8" All 
Modulo '128' Some 
More Data Bit, 'M = 1l* transmitted ALIX 
"M = 1° accepted Allx 
User Data Fields Contain Integral Number of Octets Only 
Maximum User Data Length = 128 Octets All 
= 16, 32, 64, 256, 512 or 1024 Octets Some 


*128" (Modulo '128"') 


* Some IBM SNA X.25 DTE implementations do not support the QLLC, ELLC 
and 'M’ bit procedures. They perform adjacent node services and 
segmentation/concatenation using Physical Services Headers. 


DTEs that use PSHs and do not accept 'M = 1" require the maximum 
User Data field sizes at the local and remote DTE/DCE interfaces 
to be identical. 


The Qualifier bit 'Q=1" is transmitted by IBM SNA X.25 DTEs to identify Logical Link 
Control (LLC) information. The Delivery Confirmation bit 'D=1"' is not used by IBM SNA 
X.25 DTEs. 


All IBM SNA X.25 DTEs allow modulo '8' packet sequence numbering; some may also allow 
modulo '128' packet sequence numbering. 


IBM SNA X.25 DTEs use the More Data Mark (M-bit) for packet. sequence generation and 
interpret the 'M" bit on received packets to properly reassemble received packet 
sequences. 


IBM SNA X.25 DTEs, which require user data to be an integral number of octets, 
accommodate a maximum user data field length of '128' octets. Window sizes, W, of 
1 W< 8 are used for modulo '8* packet sequence numbering. Window sizes, W, of 
1s W < 128 are used for modulo '128' packet sequence numbering. 


AMA 
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Some IBM SNA X.25 DTEs may also allow optional maximum User Data fields of '16', '32', 
"64", "256", "512", or '1024' octets. : 


3.3.1.3 Call Control 


For control of virtual calls, IBM SNA X.25 DTEs may transmit: 
1. CALL REQUEST 

2. CALL ACCEPTED 

3. CLEAR REQUEST and 

4. DTE CLEAR CONFIRMATION packets. 

They may accept and respond to: 

1. INCOMING CALL 

2. CALL CONNECTED 

3. CLEAR INDICATION and 

4. DCE CLEAR CONFIRMATION packets. 


Call control packets are used as described in reference 1. Clarifications for the use 
of call control packets on SNA-to-SNA connections are summarized in Table I-6. 


Table I-6: Use of Call Control Packets on SNA-to-SNA IBM SNA 
Connections. X.25 DTEs 


General Format Identifier 


= '9001' All 
= '0010° Some 


User 6nti On to specify Calling DTE Address in 
CALL REQUEST All 


Facilities Field in — CALL REQUEST 
| INCOMING CALL 

CALL ACCEPTED 

CALL CONNECTED 


Call User Data (CUD) Field in — CALL REQUEST and 


INCOMING CALL All 


Calling and Called DTE Address length field in 
| CALL ACCEPTED 
DTE Originated Diagnostic Code in CLEAR REQUEST All 
CLEAR INDICATION 


The General Format Identifier (GFI) is encoded '0001’° for modulo '8' packet sequence 
numbering, er '0010' when extended packet sequence numbering 1s used. 


The first octet of the Call User Data field is a Protocol Identifier (see §-6.2.1.6, in 
part II) that has particular significance and is required. In addition to the 
network-specific significance specified in CCITT Recommendation X.25 for bits 8 and 7, 
IBM SNA X.25 DTEs use: | 


° bit 2 to distinguish between SNA-to-SNA connections and SNA-to-non_SNA 
connections that may coexist at the same DTE/DCE interface; and, 


e bit 3 to specify the particular logical link control to be used on SNA-to-5SNA 
connections. 


IBM SNA X.25 DTEs set the contents of the Clearing Cause field to x'00" and place a 


diagnostic code in CLEAR REQUEST packets for delivery, by PSDNs, to partner DTEs in 
CLEAR INDICATION packets. 
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IBM SNA X.25 DTEs may optionally supply a Calling DTE address in CALL REQUEST packets. 
The facilities field in CALL REQUEST, INCOMING CALL, CALL ACCEPTED, and CALL CONNECTED 
packets may be used to specify optional user facilities. 


Some optional user facilities require explicit support functions to be provided by 
DTEs; others, designated 'User Choice’, do not. Table I-7 summarizes those facilities 
that are available with all, some or none of the IBM SNA X.25 DTEs on SNA-to-SNA 
connections. "User choice’ means that availability of the facility 1s not dependent 
upon any explicit support functions in IBM SNA X.25 DTEs; support for the facility 15s 
provided entirely on the DCE side of the X.25 DTE/DCE interface. 


When subscribed optional user facilities are indicated in INCOMING CALL packets, IBM 
SNA X.25 DTES may analyze the facility parameter field and either: 


e Accept the call with no further comment in CALL ACCEPTED packets. 
e Negotiate using the facility field in CALL ACCEPTED packets. 


® Reject the call using CLEAR REQUEST packets with an appropriate diagnostic 
Indication. 


IBM SNA X.25 DTEs may reject calls that indicate unsubscribed optional user facilities 
in INCOMING CALL packets by issutng a CLEAR REQUEST packet with an appropriate code in 
the diagnostic field. 


All IBM SNA X.25 DTEs detect national facility marker(€s) indicated in INCOMING CALL 
packets. Some may also recognize and act upon non-xX.25 facilities. 


Table I-7: Optional User Facilities IBM SNA 
for SNA-to-SNA Connections X.25 DTEs 


Nonstandard Default Packet Sizes All 
Nonstandard Default Window Sizes All 
Default Throughput Classes Assignment User Choice 
Incoming Calls Barred User Choice 
Outgoing Calls Barred User Choice 
Single Closed User Group User Choice 
Single Closed User Group with Outgoing Access User Choice 
Single Closed User Group with Incoming Access User Choice 
Incoming Calls Barred Within a Closed User Group User Choice 
Outgoing Calls Barred Within a Closed User Group User Choice 
Reverse Charging Acceptance User Choice 
One-Way Logical Channel Outgoing Some 
One-Way Logical Channel Incoming Some 
Reverse Charging Some 
Flow Control Parameter Negotiation Some 
Throughput Class Negotiation Some 
Multiple Closed User Groups Some 
Multiple Closed User Groups with Outgoing Access Some 
Multiple Closed User Groups with Incoming Access Some 
Extended Packet Sequence Numbering Some 
RPOA Selection Some 
Fast Select None 
Fast Select Acceptance None 
Packet Retransmission None 
Bilateral Closed User Group None 
Bilateral Closed User Groups with Outgoing Access None 


3.3.1.4 Error Notification in the Data Transfer Phase 

During the data transfer phase, IBM SNA X.25 DTEs convey Error Notifications across 
the DTE/DCE interface in the Cause and Diagnostic Code fields of: 

1. CLEAR REQUEST 

2. RESET REQUEST and 

3. RESTART REQUEST packets. 
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They process error notification information received from DCEs in the Cause and 
Diagnostic Code fields of: 


1. CLEAR INDICATION 
2. RESET INDICATION and © 
3. RESTART INDICATION packets. 


Contents of Diagnostic Code and Diagnostic Explanation fields of DIAGNOSTIC packets 
are used for error notification. 


These packet types are used as described under “Initialization” on page I-12 after 
link level activation and for error notification. Errors detected by DCEs are 
described in reference 1. Errors detected by IBM SNA X.25 DTEs are indicated in the 
Diagnostic Code field of CLEAR REQUEST, RESET REQUEST or RESTART REQUEST packets for 
delivery, by PSDNs, to affected remote DTEs in CLEAR INDICATION, RESET INDICATION and 
RESTART. INDICATION packets. Table I-8 provides clarifications for the use of error 
notification packets on SNA-to-SNA connections. 


Table I-8: IBM SNA X.25 DTE Use of Error Notification IBM SNA 
Packets on SNA-to-SNA Connections X.25 DTEs 
General Format Identifier (GFI) in all packets b'0001' 
: Some 


b'0010' 


Clearing Cause Field in CLEAR REQUEST packets = x'00' 


Resetting Cause Field tn RESET REQUEST packets = x'00’ All 


| Restarting Cause Field in RESTART REQUEST packets = x'00° All 
‘Diagnostic Code Field in CLEAR, RESET and RESTART REQUEST } all | 


3.3.1.5 Actions of the DTE in Unusual Circumstances 


1. DTE Time-Outs 


After issuing a CALL REQUEST, CLEAR REQUEST, RESET REQUEST and RESTART REQUEST, 
IBM SNA X.25 DTEs start a time-out. This timer jis reset upon receipt of the 
corresponding confirmation packet from the DCE. 


If the time-out expires prior to receipt of the corresponding confirmation packet 
from the DCE, IBM SNA X.25 DTEs may retransmit the request packet and restart the 
timer. This retransmission procedure may occur *n20' times. If the 
retransmission procedure is not successful, the failure is reported to the higher 
levels of SNA. 


2. DTE-Detected Errors | 
Errors detected by IBM SNA X.25 DTEs are categorized as follows: 


I - those that result from receipt of unsupported packet types (e.g., DCE 
INTERRUPT or DCE DATAGRAM packets). 


II - those that can result from discrepancies between the DTE and DCE 
interpretations of the state of some subscribed interface parameter. | 
Ce.g., receipt of an INCOMING CALL packet ona logical channel assigned 
for permanent virtual circuit service). 


III - those most likely resulting from a malfunction of the DCE (e.g., 
receipt of an unsolicited DCE RESTART CONFIRMATION packet). 


IV - those caused by failures at the physical level or the link level 
Ce.g., dropping of the Data Set Ready indication). 


For category "I' and 'II' errors, IBM SNA X.25 DTEs clear the virtual call or reset 
the permanent virtual circuit if such an action is permitted without violating any 
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procedure. The error condition is reported to the higher levels of SNA; the 
received packet 1s discarded. 


For category ‘III" errors, IBM SNA X.25 DTEs transmit a RESTART REQUEST packet 
across the DTE/DCE interface, place all virtual circuits in an inoperative state 
and report the error condition to the higher levels of SNA. 


For category 'IV' errors, IBM SNA X.25 DTEs place the LAPB link and all the virtual 
circuits at the DTE/DCE interface in an inoperative state and report an interface 
failure to the higher levels of SNA. 


3. DCE-Detected Errors 


DCEs indicate detected error types in the Cause and Diagnostic Code fields of 
RESET INDICATION, CLEAR INDICATION and RESTART INDICATION packets and in the 
Diagnostic Code and Diagnostic Explanation fields of DIAGNOSTIC packets. 


IBM SNA X.25 DTEs act as a function of the severity of the situation, taking into 
account the Call Progress Signal descriptions provided in CCITT Recommendation 
X.96. When the response to a CALL REQUEST is a CLEAR INDICATION with a cause field 
of severity Dl or D2 (as defined in CCITT Recommendation X.96) and in the case of 
local procedure errors, IBM SNA X.25 DTEs report the contents of the Clearing 
Cause and Diagnostic Code fields to higher levels of SNA and await further 
Instructions. When a RESET or CLEAR INDICATION is received during the data 
transfer phase, a virtual call is cleared and the virtual circuit is placed in an 
inoperative state, unless successful recovery is effected at the ELLC level. 
Contents of the Clearing Cause and Diagnostic Code fields are reported to higher 
levels of SNA. When a RESTART INDICATION packet is received, all of the virtual 
circuits of the DTE/DCE interface are placed in-an inoperative state unless 
successful recovery is effected at the ELLC level. Contents of the restarting 
Cause and Diagnostic Code fields are reported to higher levels. When a DIAGNOSTIC 
packet is received, contents of the Diagnostic Code and Explanation fields are 
reported to higher levels. No logical channel state changes occur as a result of 
receiving DIAGNOSTIC packets. 


4. Unsuccessful Calls 


DCEs indicate that virtual calls cannot be completed by inserting the appropriate 
codes in the Clearing Cause and Diagnostic Code fields of CLEAR INDICATION 
packets. When these codes indicate network congestion, out-of-order or number 
busy, IBM SNA X.25 DTEs either retry the operation or refer the retry to a higher 
level. The number of retries may be a system generation parameter for DTEs. 


‘3.3.2 SNA-to-non SNA Connections 


On SNA-to-non_SNA connections, the X.25 packet level functions, formats and facilities 


supported are defined by the application program as a function of the requirements of 
the non-SNA X.25 DTE. | 


In transparent operation, IBM SNA X.25 DTEs may elect to accept and transmit all 
packet formats defined in CCITT Recommendation X.25, except DTE REJECT, DATAGRAM and 
DATAGRAM SERVICE. SIGNAL packets. 


3.3.2.1 Packet Types 


The packet types shown in Table I-9 may be allowed on SNA-to-non_SNA connections in 
addition to those shown in Table I-3. 
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Table I-9: Additional Packet Types Available on 
SNA-to-~non_SNA Connections 


PACKET TYPES 


ACCEPTED — DCE INTERRUPT 
—- DCE INTERRUPT CONFIRMATION 


TRANSMITTED — DTE INTERRUPT 
—- DTE INTERRUPT CONFIRMATION 


VC — Affects given Virtual Calls 
PVC — Affects given Permanent Virtual Circuits 
IZF — Affects all VCs and PYCs at the DTE/DCE Interface 


The characteristics of data and call .control packets used for SNA-to-non_SNA 
connecticns are as summarized in Tables I-5 and I-6, respectively, for SNA-to-SNA 
connections, except that the Delivery Confirmation (€'D' bit) procedure may be used hy 
some DTEs on SNA-to-non_SNA connections. 


3.3.2.2 Use of Call Control Packets 


The first octet of the Call User Data field (called the Protocol Identifier (PI)) in 
CALL REQUEST packets is used to distinguish packets on SNA-to-SNA connections from 
those on SNA-to-non_SNA connections at a given SNA X.25 DTE/DCE Interface. The 
setting of bits 8, 7 and 2 to ‘'l's in the first octet of the Call User Data field 
indicates an SNA-to-SNA connection. | 


Codings of the first octet of the Call User Data field in which bits 8 and 7 are set to 
"1's and bit 2 is set to '0' indicates an SNA-to-non_SNA connection. 


3.3.2.3 Error Notification 


The coding of the Diagnostic Code field in RESTART REQUEST, CLEAR REQUEST and RESET 
REQUEST packets is not standardized for SNA-to-non_SNA connections. Therefore, IBM 
SNA X.25 DTEs do not assign any value to this field. However, they do accept and pass, 
to higher levels, diagnostic codes set by partner DTEs. 
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4.0 OTHER SYSTEM CONSIDERATIONS 
4.1 SECURITY 


46.1.1 SNA-to-SNA Connections 


Called DTEs can implement a rudimentary calling DTE identification check by testing 
the calling DTE address in INCOMING CALL packets. DTEs can elect to implement as a 
user option a connection identification capability defined for CALL REQUEST and 
INCOMING CALL packets. 


Care must be exercised in choosing cryptographic techniques. Data link control level 
cryptographic products defined for SNA products cannot be used at the X.25 link and 
packet levels. Cryptographic products defined for SNA above, and transparent to, the 
data link control level can be used. 


4.1.2 SNA-to-non SNA Connections 


Security techniques are specific to the particular non-SNA remote DTE being supported. 
In general, techniques used for SNA-to-SNA connections are not applicable. 


4.2 RELIABILITY, AVAILABILITY AND SERVICEABILITY (RAS) 


Errors at the X.25 DTE/DCE interface, either detected by IBM SNA X.25 DTEs or 
indicated by their associated DCEs, are reported to the SNA control point or toa local 
operator, as appropriate. The network-generated Cause and Diagnostic Codes defined in 
CCITT Recommendation X.25, and a common set of DTE-originated diagnostic codes defined 
for SNA-to-SNA connections, are used for reporting purposes to aid In problem 
determination. Session outage notifications are propagated in accordance with general 
SNA mechanisms pertaining to link/station failures. 
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PART II 


CCITT Recommendation X.25 (Geneva, November 1980) defines an interface between 
customer data terminal equipment (DTE) and data circuit-terminating equipment (DCE). 
It is designed to facilitate the attachment of DTEs to packet-switched data networks 
CPSDNs). The definition includes three independent elements: 


1. Physical Level - the mechanical, electrical, functional and procedural 
characteristics to activate, maintain and deactivate physical communication links 
between DTEs and DCEs. 


2. tink Level - the link access procedure for the interchange of data across 
communication links between DTEs and DCEs. 


3. Packet Level - the packet formats and control procedures for the exchange of 
control information and user data, or both, between DTEs and DCEs. 


Other international standards explicitly or implicitly referenced tn this 
document include: 


a. CCITT Recommendation X.1 - International User Classes of Service tn Public 
Data Networks. 


b. CCITT Recommendation X.2 - International User Services and Facilities in 
Public Data Networks. 


c. CCITT Recommendation X.21 - Interface between Data Terminal Equipment (CDTE) 
and Data Circuit-Terminating Equipment (DCE) for synchronous Operation on 
Public Data Networks. | 

d. CCITT Recommendation X.21_bis ~- Use on Public Data Networks of Data Terminal 
Equipment (DTE) which are Designed for Interfacing to Synchronous V-Series 
Modems. 

e. CCITT Recommendation X.96 - Call Progress Signals in Public Data Networks. 


f. CCITT Recommendation X.119 - Routing Principles for International Public Data 
Services through Switched Public Data Networks of the Same Type. 


g. CCITT Recommendation X.121 - International Numbering Plan for Public Data 
Networks. 


CCITT Recommendation X.25 focuses on a description of the DTE/DCE Interface functions 


from the perspectiva of DCEs. This manual focuses on the same interface from the 
perspective of DTEs. Thus, several instances occur where the term DTE or DCE is 
replaced by the word station(s). Other substantive differences between the two 


interface descriptions are identified by vertical bars (])} in the left margin of this 
manual. Text in this edition of the manual that has been changed or extended for 
clarification or to correct errors found in the second edition, as well as that 
required to accommodate and describe the enhanced logical link control protocol is 
identified by the figure '2' in the left margin. 


Note: 


1. The bit/byte numbering used throughout this manual is consistent with the - 
numbering used in CCITT Recommendation X.25 (1980) and may, therefore, differ from 
that with which the reader may be more familiar. 


2. Network specific interface requirements, that deviate from the interpretation of 

, CCITT Recommendation X.25 (Geneva, November 1980) reflected in this document, may 
be considered by IBM SNA X.25 Product Managers on an individual basis, in making 
technical and business judgements regarding possible justification for the 
support of such deviation(s). Network specific interface requirements are not 
defined in this manual. | 


This part describes the X.25 DTE/DCE Interface as perceived by IBM SNA X.25 DTEs, 
based on CCITT Recommendation X.25 as published in the "Yellow Book’ instead of the 
version adopted by the VIIIth Plenary Assembly in 1984 to be published in the 'Red 
oe sometime in 1985, and is composed of nine sections and several appendices as 
Tollows: , | 


PART II | II-vi 


Section 1 - DTE/DCE Interface Characteristics - specifies the physical level 
interface used between IBM SNA X.25 DTEs and their associated DCEs. 


Section 2 - Link Access Procedure Across the DTE/DCE Interface - specifies the 
link level interface used for the interchange of data via communication links 
between IBM SNA X.25 DTEs and their associated DCEs. 


Section 3 - Description of the Packet Level DTE/DCE Interface - describes the 
packet level procedures used to exchange control information and user data at the 
X.25 DTE/DCE interface. 


Section 4 - Procedures for Virtual Circuit Services - describes the procedures 
used for virtual call and permanent virtual circuit services. 


Section 5 - Procedures for Datagram Services ~ is not applicable for IBM SNA X.25 
DTEs. 


Section 6 - Packet Formats - specifies the formats for packets exchanged between 
IBM SNA X.25 DTEs and their associated DCEs. 


Section 7 ~ Procedures and Formats for Optional User Facilities - specifies the 
optional user facilities allowed by IBM SNA X.25 DTEs and the procedures and 
formats for their selection and use. 


Section 8 - Logical Link Control (LLC) on SNA-to-SNA Connections - defines the 
format and use of 'Qualified' data packets to perform adjacent SNA node physical 
services. 


Section 9 - Other System Considerations - describes some other considerations for 
the use of IBM SNA X.25 DTEs in Packet-Switched Data Network environments. 


Appendix A - defines the range of logical channels used for virtual calls and 
permanent virtual circuits. 


Appendix B - defines the states of the packet level at the X.25 DTE/DCE interface. 


Appendix C - describes the actions taken by DCEs on receipt cf packets tna given 
state of the packet level X.25 DTE/DCE interface as perceived by DCEs. 


Appendix D - defines packet level DCE time-outs and DTE time-limits. 


Appendix E - specifies the diagnostic codes generated by DCEs employing CCITT 
Recommendation X.25 for CLEAR, RESET INDICATION, RESTART INDICATION and 
DIAGNOSTIC packets. 


Appendix F - specifies the diagnostic codes generated by IBM SNA X.25 DTEs for 
CLEAR REQUEST, RESET REQUEST and RESTART REQUEST packets on SNA~-to-SNA 
connections. 


Appendix G - describes the actions taken by IBM SNA X.25 DTEsS on receipt of 
packets ina given state of the packet level of the X.25 DTE/DCE interface as 
perceived by DTEs. 


Appendix H - describes the Physical Services Header (PSH) used on SNA-to-SNA 
connecticns to an IBM 5973 Network Interface Adapter (NIA). 


Appendix I - describes some architectural considerations for SNA-to-non SNA 
connections. 


Appendix J - describes the actions taken by IBM SNA X.25 DTEs upon occurrence of 
events in the various states of the link layer interface. 


Appendix K - describes the formats, protocols and procedures employed by IBM SNA 


X.25 DTEs for an enhanced locical link control between adjacent nodes on 
SNA-to-SNA connections. 
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1.6 DTE/DCE YNTERFACE CHARACTERISTICS - (PHYSICAL LEVEL) 


The DTE/DCE physical interface characteristics defined as the Physical Level element 
shall be in accordance with CCITT Recommendation X.21. For an interim period, some 


‘Common Carriers, Administrations or Recognized Private Operating Agencies (RPOAS) may 


offer a DTE/DCE interface at this level in accordance with Recommendation X.21 bis. 
The exact use of the relevant points in these Recommendations is detailed in the 
fallowing points of this specification. 


X.21 and X.21 bis as defined in CCITT Recommendations V.24 and V.35 for leased service 
only are used. 


1.1 DEDICATED ACCESS 


The interface characteristics for DTEs connected to packet-switched data transmission 
=p cheek by dedicated circuits are described in "X.21 Interface” through "X.21_bis 
mterface." 


1.3.1 *X.21 Interface 
1.1.1.1 Elements 
The DTE/DCE physical interface elements shall be according to $§$-2 of CCITT 


Recommendation X.21. 


1.1.1.2 Test Loops 


The operation of test loops shall be according to §$-7 of CCITT Recommendation X.21. 


1.3.1.3 Procedures 


The procedures for entering operational phases shall be as follows: 


1. when the DTE signals 'c=0N', signals on circuit ‘'T" shall be according to the 
higher level procedures described in the following points of this Specification. 


2. when the DCE signals ‘i=ON', signals on circuit 'R* shall be according to the 
higher level procedures described in the following points of this Specification. 


3. the DTE/DCE interface should normally remain in the operational condition with 
both 'c=O0N" and 'i=ON’ to enable proper operation of the higher level procedures 
described in the following points of this Specification. 


4. if a situation necessitates the DTE to signal DTE ready or DTE uncontrolled not 
ready, or the DCE to signal DCE ready or DCE not ready, the interface should return 
to the operational condition with both ‘'c=ON' and ‘"'i=ON' when the situation is 
appropriate to enable normal operation of the higher level procedures described in 
the following points of this Specification. 


1.1.2 X.21 bis Interface 
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1.1.2.1 Elements 


The DTE/DCE physical interface elements shall be according to §-1 of CCITT 
Recommendation X.21_bis. a 4 


1.1.2.2 Problem Determination 
Failure detection and fault isolation shall be according to §-3 of CCITT 
Recommendation X.21_bis. | 


Note: - The addition of circuit #142 (Test) is considered a future requirement for 
IBM SNA X.25 DTEs. | 


1.1.2.3 Procedures 


When circuits 105, 106, 107, 108 and 109 are in the 'ON' condition, signals on circuits 
103 and 104 shall be according to the higher level procedures described in the 
following points of this specification. 


i.2 SWITCHED ACCESS 


The interface characteristics and procedures for DTEs connected to packet-switched 
data transmission services through circuit-~switched data transmission services are 
not allowed in SNA environments. 


(Text deleted). 


1.3 ACCESS SPEEDS 
IBM SNA X.25 DTEs support one or more of the following CCITT recommended data 
transmission speeds: 


2.4, 4.8, 9.6 or 48.0 Kbit/s. 


Additional data transmi 


DTEs include: 
1.2, 19.2, 56.0 and 64.0 Kbit/s. 
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2.0 LINK ACCESS PROCEDURE ACROSS THE DTE/DCE INTERFACE 
2.1 SCOPE AND FIELD OF APPLICATION 


2.1.1 The Link Access Procedure (LAPB)(text deleted) 


LAPB is described as the Link Level Element used for the interchange of data between 
DCEs, operating in user classes of service 8 to 11 as indicated in CCITT 
Recommendation X.1, and IBM SNA X.25 DTEs. 


2.1.2 Principles and Terminology 


The procedure uses the principle and terminology of the High Level Data Link Control 
CHDLC) procedures specified by the International Organization for Standardization 
CISO0}. 


2.1.3 The transmission facility is duplex, 


2.1.4 IS0 Compatibility 


Station CDCE and DTE) compatibility of operation with the ISO balanced class of 
procedure (Class BA, options 2 and 8) is achieved using the provisions found under the 
headings annotated as (LAPB) in this specification. 


(Text deleted.) 


Note: Other possible applications being considered by the CCITT include: 


e (Text deleted. ) 
® ~ two-way alternate, normal response mode. | 


2.2 FRAME STRUCTURE 


2.c.1 Format 


All transmissions across the X.25 DTE/DCE interface are in frames conforming to one of 
the formats shown in Table II-1. The flag preceding the address field is defined as 
the opening flag. The flag following the Frame Checking Sequence (FCS) is defined as 
the closing flag. 


2.2.¢ Flag (F) Sequence 


All frames shall start and end with at least one flag sequence consisting of at least 
one '0" bit followed by six contiguous '1' bits and at least one "0° bit €'01111110'). 
A single flag sequence may be used as both the closing flag for one frame and the 
opening flag for the next frame. IBM SNA X.25 DTEs transmit and receive bit 
configurations *...0111111001111110..." as flag sequences and receive and interpret 
bit configurations *...011111101111110...' as flag sequences. 
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The & field is a single octet, positioned as shown in Table II-1 and coded as descevbod 
in "Procedure for Addressing (Text deleted)™ on page II-14. 


2.2e-% Control (C) Field 


The C field is a single octet, positioned as shown in Table II-1 whose content is 
described in "Control Field Formats and State Variables" on page II-6. 


Note: Passible extension of the control field is being considered by the CCITT. 


TABLE II-1 — Frame Formats 


Order of Bit 
Transmission 12345678 12345678 12345678 16 to 1 12345678 


[Fias | Address] contro] Fos | Flag 


FCS 
F A C FCS F 
01111110] 8—-bits 8—-bits 16—-bits /01111110 


Order of Bit 
Transmission 12345678 12345678 12345678 123....... n 16 to 1 12345678 


[address] Controi [information] Fes [ Flag 


FCS 
F A C I . FCS F 
01111110] 8&—-bits 8&—-bits N-Octets® {16—bits/01111110 


FCS = frame checking sequence 
¥ —~ Octet is an 88-bit byte. 


The I-field of all frames transmitted and received by IBM SNA X.25 DTEs must contain an 
integral number of octets and is unrestricted with respect to code or grouping except 
for the packet formats specified in "PACKET FORMATS” on page II-4%6, the 'Qualified' 
data packet formats for SNA-to-SNA connections shown in "Logical Link Control (LLC) on 
SNA-to-SNA Connections"™ on page II-83 and the Physical Services Header (PSH) formats 
for SNA-to-SNA connections described in Appendix H. . 


Note: Frames containing other than an integral number of octets are ignored by IBM 
SNA X.25 DTEs at the link level. 


See "(Text deleted); Frame Reject (FRMR) Response” on page II-11 and "Maximum Number 
of Bits in an I-frame, Ni" on page [I-23 below with regard to the maximum information 
field length. 


2.c.6 Transparency 


Transmitting stations examine the frame content between the two flags including the 
address, control, information and FCS and insert a '0' bit immediately following all 
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sequences of 5 contiguous ‘'1* bits Cincluding the last 5 bits of the FCS) to ensure 
that a flag 1s not simulated by data on the line. Receiving stations examine the frame 
content and discard any '0' bit that immediately follows 5 contiguous '1' bits. 


2.2.7 Frame Checking Sequence (FCS) 


The FCS is a 16-bit sequence containing the ones complement of the sum (modulo 2) of: 


1. The remainder of Xk(X!5 + X?5 + Xi3 + 1... + X2 + X + 1) divided (modulo 2) by the 
generator polynomial X!?° + X!2 + X5 +1, where k is the number of bits in the frame 
existing between, but not including, the final bit of the opening flag and the 
first bit of the FCS, excluding bits inserted for transparency, and 


2. the remainder after multiplication by X!© and then division (modulo 2) by the 
generator polynomial X!® + X!2 + X5 + 1, of the content of the frame, existing 
between but not including, the final bit of the opening flag and the first bit of 
the FCS, excluding bits inserted for transparency. 


As a typical implementation, at transmitting stations, the initial remainder of the 
division is preset to all ones and is then modified by division by the generator’ 
polynomial Cas described above) on the address, control and information fields; the 
ones complement of the resulting remainder is transmitted as the 16-bit FCS. 

At receiving stations, the initial remainder is preset to all ones, and the serial 
incoming protected bits and the FCS when divided by the generator polynomial will 


result in a remainder of '0001110100001111' (X!5 through X°, respectively) in the 
absence of transmission errors. 


2.2.8 Order of Bit Transmission 


Addresses, commands, responses, sequence numbers and information octets are 
transmitted with the low order bit first (for example the first bit of the sequence 
number that is transmitted has the weight 2°). 


(Text deleted). The FCS shall be transmitted to the line commencing with the 
coefficient of the highest term. 


Note: The low order bit is bit 1, as depicted in Tables II-1 to II-4. 


2.2.9 Invalid frames 


Frames not properly bounded by two flags, or having fewer than 32 bits between flags, 
are invalid. 


2.2.10 Frame abortion 


A frame being transmitted may be aborted by the transmission of an abortion sequence 
Ce.g., at least seven (7) contiguous '1' bits Cwith no inserted '0's)). 


2.2.11 Interframe Time-Fill 


The transmission of contiguous flags between frames is defined as interframe 
time-fill. 
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2.c.le2 Link Channel States 


22.12.11 Active Channel State 


A channel is ‘active’ when the transmitting station is actively transmitting a frame, 
an abortion sequence or interframe time-fill. 


2.2.l2.2 Idle Channel State 

A channel is ‘idle’ when a contiguous 'l's condition is detected, by the receiving 
station, that persists for at least fifteen (15) bit times. 

IBM SNA X.25 DTEs detect the idle channel state and may consider it to be either: 

e an indication that the DCE is not able to support link set-up; 

e a simple indication that the DCE has temporarily suspended transmission; or, 

© an indication that the link is in the disconnected phase if a flag sequence is not 


received within at least time Ti. Ti is defined in "DTE Timer, Ti™ on page II-23. 


Note: 


1. The action to be taken by DCEs upon detection of the idle channel state is a 
subject for further study by the CCITT. 


2. A link channel as defined here is the means of transmission for one direction. 
2.3 ELEMENTS OF PROCEDURE 


2.3.1 Introduction 


The elements of procedure are defined in terms of actions that occur on receipt of 
commands at receiving stations. 


The elements of procedure specified here contain a salection of commands and resp 


relevant to the link and system configuration described in "Scope and Field 
Applicatton™ on page II-3. 


A procedure is’ derived from these elements of procedure and is described in 
"Description of the Procedure" on page II-14. Together "Frame Structure” on page II-3 


and “Elements of Procedure" form the general requirements for proper management of the 
access link connecting DCEs and IBM SNA X.25 DTEs. 


e.3.e¢ Control Field Formats and State Variables 


2.3.2.1 Gontrol (C} Field Formats 


The C field contains a command or a response, and sequence numbers where applicable. 
Three C-field formats (see Table II-2) are used to perform numbered information 


‘transfers (I-frames), numbered supervisory functions (S-frames) and unnumbered 
control functions (U-frames). 
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TABLE II-2 — Control Field Formats 
Control field bits 


transmitter send sequence number (bit 2 = low order bit). 
transmitter receive sequence number (bit 6 = low order bit). 
supervisory function bit. 

modifier function bit. 

poll (P) bit in command frames or final (CF) bit in response 
frames (1 = Poll/Final). 


1. Information Transfer Format — I 


The I format is used to perform information transfers. The functions of Ns, Nr and 
P/F are independent; i.e., each I-frame has an Ns, and an Nr which may or may not 
acknowledge additional I-frames received by the station transmitting the Nr, anda 
P/F bit. 


2. Supervisory Format — S 
The S format is used to perform link supervisory control functions such as 
acknowledging I-frames, requesting retransmission of I-frames, and requesting 
temporary suspension of transmission of I-frames. 


3. Unnumbered Format — U 


The U format is used to provide additional Link control functions. This format 
contains no sequence numbers. 


(Text deleted. ) 


2.3.2.2 Control Field Parameters 


The various parameters associated with the control field formats include a modulus and 
frame variables and sequence numbers. 


2.3.2.3 Modulus 


Each I-frame is sequentially numbered and may have the value ‘'Ns=0' through 
"Ns=modulus minus one’ (where "modulus" is the modulus of the sequence numbers). The 
modulus equals '8' and the sequence numbers cycle through the entire range '0" to '7', 
inclusive. 


2.3.-c-% Frame Variables and Sequence Numbers 


1. Send State Variable 


The send state variable (Vs) denotes the sequence number of the next in-sequence 
I-frame to be transmitted. Vs can take on the value '0' through ‘modulus minus 
one’. The value of Vs %5S tnecremented by one with each successive I-frame 
transmission, but at transmitting stations cannot exceed Nr of the last received I 
or S-frame by more than the maximum permissible number of outstanding IJ-frames 

~(K). The value of 'K' is defined in "Maximum Number of Outstanding I-frames, K" on 
page I[I-23. 


2. Send Sequence Number 
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Only I-frames contain Ns, the send sequence number of transmitted frames. Prior 
to transmitting an in-sequence I-frame, the value of Ns is set equal to the value 
of Vs at the transmitting station. | | 


3. Recetve State Variable 


The receive state variable (Vr) denotes the sequence number of the next 
in-sequence I-frame to be received at receiving stations. Vr can take on the 
values '0' through 'modulus minus one’. The value of Vr:is incremented by one upon 
receipt of each error free, in-sequence (with an Ns that is equal to the current 
value of Vr at the receiving station) I-frame. 


4. Receive Sequence Number 


All I frames and S~-frames contain Nr, the expected sequence number of the next 
recetved I-frame. Prior to transmitting an I or S-frame, Nr is set equal to the 
current value of Vr at the transmitting station. Nr indicates that the station 


transmitting the Nr has correctly received all I-frames numbered up to and 
including 'Nr-1'. 


2.3.3 Functions of the Poll/Final Bit 


The poll/final CP/F) bit serves a function in both command frames and response frames. 
In command frames the 'P/F' bit 1s referred to as the Poll (P) bit. In response frames 
1t 1s referred to as the Final (CF) bit. 


Procedures for use of the 'P/F* bit are described in "Procedure for Use of the P/F Bit. 
Ctext deleted)” on page II-14. 


2.3.% Commands and Responses 


Commands and responses transmitted and received by DCEs operating in LAPB mode and IBM 
SNA X.25 DTEs are described in "Information (I) Command" on page II-9 through "(Text 
deleted); Frame Reject CFRMR) Response” on page II-11 and are depicted in Table II-3. 
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TABLE II-3 — Commands and Responses 


Information Nr 
transfer 
RR 


Supervisory RR 


Oc 
~ 
Oo 
ui 
oo 
Ww 


RNR 
(See Note) 


Unnumbered 
(See Note) 


© 
ZZ 
73 


0 1 
1 
0 


p— 


oO 
ofr 


Disconnect 

Disconnected Mode 

Frame Reject 

Information 

Reject 

Receive Not Ready 

Receive Ready 

Set Asynchronous Balanced Mode 
Unnumbered Acknowledgement 


SNA X.25 DTEs with 'P=1'; Information transfer frames are 
transmitted by IBM SNA X.25 DTEs with ‘'P=0"'. 


| Note: All Supervisory and Unnumbered Commands are transmitted by IBM 


| (Text deleted. ) 


2.3.4.1 Information (I) Command 


I commands are used to transfer sequentially numbered frames, that contain information 
| fields, across data links connecting X.25 DCEs and IBM SNA X.25 DTEs. 


2.3.4.2 Receive Ready (RR) Command and Response 


RR supervisory frames are used by transmitting stations to: 


ee indicate that they are ready to receive I-frames; 
2. acknowledge previously received I-frames numbered up to and including 'Nr-l’. 


RR frames may be used to clear busy conditions initiated by the transmission of RNR 
frames. RR commands with 'P=1' may be used by transmitting stations to solicit the 
status of remote stations. 


2.3.4.3 Reject (REJ) Command and Response 


REJ supervisory frames are used by transmitting stations to request retransmission of 
I-frames starting with the frame numbered Nr. I-frames numbered 'Nr-1' and below are 
acknowledged. Additional I-frames pending initial transmission may be transmitted 
following the retransmitted I-frame(s). 


Only one REJ exception condition for a given direction of information transfer may be 
established at any time. REJ exception conditions are. cleared (reset) upon receipt of 
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an I-frame with an Ns equal to the Nr contained in the REJ frame. REJ commands with 
eee "P=3" may be used by transmitting stations to solicit the status of remote 
stations. . . 


2.3.4.4 Receive Not Ready (RNR) Command and Response 


RNR supervisory frames are used by transmitting stations to indicate busy conditions; 
i.@., temporary inability to accept additional I-frames. I-frames numbered up to and 
including 'Nr-1' are acknowledged. I-frame Nr and subsequent I-frames received, if 
any, are «ot acknowledged; the acceptance status of these I-frames is indicated in 
subsequent exchanges. 


Indication that a busy condition at a transmitting Station has cleared is communicated 
to the remete station by the transmission of a UA, RR, REJ or SABM. 


RNR commands with the "P=1' may be used by transmitting stations to solicit the status 
of remote stations. 


Upon receipt of an RNR command or response IBM SNA X.25 DTEs start timer Tp 1f it is 
not runnang. It timer Tp then expires prior to the receipt of a UA, RR, REJ or SABM, 
IBM SNA X.25 DTEs perform the retransmission procedure described in “"Time-Outs and 
Time-Limtts”™ on page II-22 before declaring the link (station) to be inoperative and 
reporting the condition to a higher level. 


Note: If unacknowledged frames are purged, by the DTE or DCE, as a result of sending 
or receiving an SABM or UA, notification must be signalled to a higher level to protect 
tne integrity of the system unless ELLC 1s being used. 


2.3.4.5 set Asynchronous Response Mode (SARM) Command 


SARM commands are not transmitted, and result in a frame rejection condition when 
received, by IBM SNA X.25 DTEs. 


(Text deleted). 


2.3.4.6 Set Asynchronous Balanced Mode (SABM) Command 


Unnumbered SABM commands are used by transmitting stations to place the remote station 
in the asymchronous balanced mode (CABM) information transfer phase. 


No information field is permitted with the SABM command. Receiving stations confirm 
acceptance of SABM commands by transmitting a UA response at the first opportunity. 
Upon acceptance of a SABM command receiving stations set both Vs and Vr equal to 'O'. 
IBM SNA X.25 DTEs always transmit SABM commands with 'P=1'. 


Previously transmitted I-frames that are unacknowledged when a SABM command is 
executed remain unacknowledged (see "Waiting for Acknowledgement” on page II-19). 


Note: If unacknowledged frames are purged, by the DTE or DCE, as a result of sending 
or receiving an SABM-or UA, unless ELLC is being used, notification must be given to a 
higher level so that the DTE/DCE packet level interface can be restarted to protect 
the integrity of the system. | 


2.3.4.7 Bisconnect (DISC) Command 


Unnumbered DISC commands are used by transmitting stations to terminate the 
operational mode previously set. DISC informs the receiving station that the 
transmitting station 1S suspending operation. 
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No information field is permitted with DISC commands. Prior to executing DISC 
commands, receiving stations confirm acceptance by transmitting a UA response. 
Transmitting stations enter the disconnected phase upon receipt of the acknowledging 
UA response. IBM SNA X.25 DTEs always transmit DISC commands with 'P=1'. Previously 
transmitted I-frames that are unacknowledged when the DISC command is executed remain 
unacknowledged (see "Waiting for Acknowledgement” on page II-19). 


Note: If unacknowledged frames are purged, by the DTE or DCE, as a result of sending 
or receiving an SABM or UA, unless ELLC is being used, notification must be given toa 
higher level so that the DTE/DCE packet level interface can be restarted to protect 
the integrity of the system. 


2.3.%.8 Unnumbered Acknowledgement (UA) Response 


Unnumbered UA responses are used by transmitting stations to acknowledge receipt and 
indicate acceptance of SABM and DISC commands. Receiving stations transmit a UA 
response before executing the received U conmand. The UA response is transmitted with 
"F=1' when 'P=1' in the received U command. No information field is permitted with UA 
responses. 


2.3.4.9 Disconnected Mode (DM) Response 


Unnumbered DM responses are used to report a status where the transmitting station is 
logically disconnected from the link, and is jin the disconnected phase. The DM 
response may be sent in this phase to request a set mode command, or, if sent in 
response to the receipt of an SABM command, to inform the remote station that the 
transmitting station is still in disconnected phase and cannot execute the SABM 
command. No information field is permitted with the DM response. 


Stations in the disconnected phase monitor received commands and: 


e react to SABM and DISC commands as described in "Procedures for Link Set-Up and 
Disconnection CLAPB)"™ on page II-15; and, 


° respond DM with 'F=1' to any other command received with 'P=1'. 


2.3.%4.10 (Text deleted}; Frame Reject (FRMR) Response 


(Text deleted) 


FRMR responses are used by stations to report error conditions that are not 
recoverable by retransmission of the identical frame to the remote station; 1.e., one 
of the following conditions, resulting from the receipt of a frame without FCS error: 


e a command or response that 1s invalid or not implemented; 

° an information field that exceeds the maximum permissible length; 

e an invalid Nr (text deleted); or, 

° an information field which is not permitted or an S or U frame of incorrect length. 


An invalid Nr is one that points to an I-frame that has been previously transmitted and 
acknowledged or to an I-frame that has not been transmitted and is not the next 
sequential I-frame pending transmission. | 


An information field which immediately follows the control field, and consists of 3 


octets, is returned with the (text deleted) FRMR response. This format 1s shown in 
Table 4. 
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TABLE II-—4 — FRMR Information Field Format 
I-field bits 
2 7 


Rejected Frame 


Control Field 


® Rejected frame control field is the control field of the received frame that 
caused the (text deleted) frame reject. 


e Vs is the current value of Vs at the station reporting the rejection condition 
Cbit 10 = low order bit). 


e Vr is the current value of Vr at the station reporting the rejection condition 
(bit 14 = low order bit). 


e "'W=1" indicates that the control field received and returned in bits 1 through 8 
was considered invalid or not implemented. 


e "X=1' indicates that the control field received and returned in bits 1 through 8 
was considered invalid because the frame contained an information field which is 
not permitted or is an S$ or U-frame with incorrect length. '‘'W=1' in required in 
conjunction with this bit. 


e "y=" indicates that the information field received exceeded the maximum 
established capacity of the station reporting the rejection condition. 


® "Z=1' indicates that the control field received and returned in bits 1 through 8 
contained an invalid Nr. 


Note: (Text deleted) Bit 13 is set to: 


"1' aif the frame rejected was a response; or, 
"OO" If the frame rejected was a command. 


2.3.5 Exception Cond:rticn Reporting and Recover 


Procedures to effect recovery following the detection/occurrence of exception 
conditions at the link level are described in "Busy Condition” through "Rejection 
Condition” on page II-13. Exception conditions described include situations that may 
occur as the result of transmission errors, station malfunctions or abnormal 
operational situations. 


2.3.5.1 Busy Condition 


’ busy condition results when a station is temporarily unable to continue receiving 
I-frames due to internal constraints (e.g., receive buffering limitations). 
Notification of the busy condition is conveyed to the remote station by transmitting 
an RNR frame across the DTE/DCE interface. I-frames pending transmission may be 
transmitted by stations experiencing a busy condition, either prior to, or following, 
transmission of the RNR frame. Recovery from ae busy condition is indicated by 
stations as described in "Receive Not Ready (RNR) Command and Response" on page JI-10. 


2.3.5.2 NS Sequence Error 


A sequence exception condition results when an error-free (no FCS error) I-frame with 
an Ns that is not equal to the current value of Vr at the receiving station is 
received. Receiving stations do not acknowledge Cincrement their Vr) I-frames that 
result in sequence exception conditions. 
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The information field of all I-frames received with an Ns that is not equal the current 
value of Vr at the receiving station is discarded. 


Stations that receive one or more I-frames having sequence errors but otherwise 
error-free accept the control tnformation contained in the Nr field and the 'P' bit to 
perform link control functions (Ce.g., to receive acknowledgement of previously 
transmitted I-frames and to cause the station to respond C'P=1"')). Therefore, 
retransmitted I-frames may contain an Nr field and ‘'P' bit that are updated, and 
therefore different from, those contained in the originally transmitted I-frame(s). 


2.3.5.3 REJ Recovery 


REJ frames are transmitted by stations to initiate exception recovery Cretransmission) 
following detection of sequence errors. 


Only one "sent REJ"™ exception condition for a station 1s estabiished at a time. A 
"sent REJ" exception condition is cleared when the requested I-frame is received; or, 
when a link set-up or disconnection procedure as described in "Link Set-up" on page 
II-15 or "Link Disconnection" on page II-16 is performed. 


Stations receiving REJ initiate sequential (Cre-)Jtransmission of I-frames starting 
with the one tndicated by the Nr contained in the received REJ frame. 


2.3.5.4 Reply Time-out Recovery 


If, due to a transmisston error, a station does not receive (Cor receives and discards) 
a single I-frame or the last I-frame in a sequence of I-frames, it cannot detect an 
out-of-sequence exception condition and will, therefore, fail to transmit REJ. DCEs 
shall, following the completion of a system specified time-out period (see "Time-Outs 
and Time-Limits™ on page JI-22), take appropriate recovery action to determine at 
which I-frame retransmission must begin. 


IBM SNA X.25 DTEs use the lost reply protection mechanism, described in "Deadlock 
Protection™ on page II-14, after a system specified time-out period (see "Time-Outs 
and Time-Limits™ on page  I[I-22), to determine at which I-frame to begin 
retransmission. 


2.3.5.5 FCS Error, Unknown Address and Invalid Frame 


Any frame received with an FCS error, an unknown address (i.e.,other than 'A* or "B*) 
or that 1s invalid (see "Invalid frames" on page II-5) 1s discarded and no action is 
taken by the receiving station as the result of such frame(s). 


2.3.5.6 Rejection Condition 


A rejection condition is established upon receipt of an error-free frame that contains 
an invalid command/response in the C field, an invalid frame format, an invalid Nr 
(text deleted) or an information field that exceeds the maximum information field 
length that can be accommodated. 


Receiving stations report exception conditions to the remote station by transmitting a 
(text deleted) FRMR response. Stations that receive a FRMR response are responsible 
for returning the the link to operational mode by transmitting an SABM command. After 
transmitting a FRMR response, stations maintain the frame rejection condition until 
reset by the remote station. I-frames received by stations in the frame rejection 
condition are discarded, except for the 'P' bit indication (Nr is ignored). The (text 
deleted) FRMR response may be repeated at each opportunity until recovery is effected 
by the remote station, or until internal recovery 1s initiated locally. 
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2.4 DESCRIPTION OF THE PROCEDURE 


Tables J-1, -2, -3 and -4 in appendix J formalize the actions taken, frames 
transmitted and state transitions made by DTEs as a result of events occurring in the 
various states of the X.25 DTE/DCE Link Level interface. 


2.4.1 Procedure to Set the Mode Variable B (Text Deleted) 
Mode variable procedures are not required in SNA environments since only balanced mode 
CLAPB) procedures are allowed. 


(Text deleted). 


2.4.2 Procedure for Addressing (Text deleted) 


Frames containing commands transferred from: 


DCEs contain the address ‘'A*. 
DTEs contain the address 'B’. 


Frames containing responses transferred from: 


DCEs contain the address 'B’. 
DTEs contain the address '"A*. 


Addresses, A and B, are coded as follows: 
| Address 87654321 
A 00000011 
B 00000001 


Note: Stations (DCEs and DTEs) discard all frames received with an address other than 
TAY or YBr. 


c¢.%4.3 Procedure for Use of the P/F Bit (text deleted) 


Upon receipt of any command frame with '‘'P=1', receiving stations transmit an 
appropriate response frame with 'F=1' at the first opportunity Ce.g., immediately 
following the frame currently being transmitted, if any). Appropriate responses 
include: 

e a UA or DM response to received SABM and DISC command frames; 

e an FRMR, REJ, RNR or RR response to received I-frames; and, 

° an FRMR, RNR or RR response to received supervisory command frames. 


The '*P* bit is also used in conjunction with timer recovery conditions as described in 
"Waiting for Acknowledgement" on page II-19. CText deleted). 


2.4.3.1 Deadlock Protection 


Transmitting stations provide a time-out function to protect against dead-lock 
conditions caused by the loss of responses from the remote station due to transmission 
errors. A timer Tl Cor Tp for DTEs) may be started upon transmission of I-frames or 
supervisory command frames, or both, during the information transfer phase. Timer Tl 
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Cand Tp for DTEs) is also used during link set-up and disconnection as described in 
"Link Set-up” on page II-15 and "Link Disconnection” on page II-16, respectively. 


If timer Tl (Cor Tp for DTEs) expires prior to receipt of an appropriate response frame 
from the remote station, recovery action i158 initiated by the local = station. 
Transmitting stations transmit an aporopriate supervisory command frame or retransmit 
the appropriate I-frame with 'P=1' and restart timer Tl (Cor Tp for DTEs). If timer Tl 
expires prior to receipt of an appropriate response with 'F=1' from the remote station 
N2 times, appropriate recovery action is initiated by the DCE. 


Upon expiration of timer Tp prior to receipt of an appropriate response with ‘'F=l1', 
IBM SNA X.25 DTEs perform the retransmission procedure described in "Time-Outs and 
Time-Limits™ on page II-22 before declaring the link (station) to be inoperative and 
reporting the condition to a higher layer. 


2.4.4 Procedure for Link Set-Up and Disconnection (LAP) 


Unbalanced Link Access Procedures (LAP) are not allowed in SNA environments. (Text 
deleted) 


2.4.5 Procedures for Link Set-Up and Disconnection (LAPB) 


2.4.5.1 Link Set-up 


Stations indicate their ability to set up the link by transmitting contiguous flag 
sequences Cactive channel state). 


Upon receipt of a SABM command, receiving stations prepared to receive I-frames return 
a UA response and set both Vs and Vr equal to '0'. Stations that for some reason are 
unable, or do not desire, to enter the information transfer phase return a DM response 
to received SABM commands. 


DTES wishing to set-up the link transmit a SABM command with 'P=1' and start timer Tp 
(see "Deadlock Protection" on page II-14). Upon receipt of a UA response with 'F=1' 
from the DCE, DTEs set both Vs and Vr equal to '0' and stop timer Tp. 


IBM SNA X.25 DTEs should always take the initiative in the link level initialization 
procedure by sending SABM with 'P=l1'. 


Upon receipt of a DM response with '‘'F=l1' indicating that the DCE cannot accept 
activation of the link, DTEs must report the condition to a higher layer and take no 
further action. | 


Upon expiration of timer Tp prior to receipt of an appropriate response with '‘'F=l1', 
IBM SNA X.25 DTEs perform the retransmission procedure described in "Time-Outs and 
Time-Limits™ on page II-22 before declaring the link (station) to be tnoperative and 
reporting the condition to a higher layer. 


DCEs wishing to set-up the link, transmit a SABM command and start Timer Tl (see 
"Time-Outs and Time-Limits” on page II-22). Upon reception of a UA response from the 
DTE, DCEs reset both Vs and Vr to '0' and stop Timer Tl. 


Should timer Tl expire before reception of the UA response from the DTE, DCEs 
retransmit the SABM command and restart Timer Tl. After transmission of the SABM 
command N2 times by the DCE, appropriate recovery action is initiated. The value of N2 
1s defined in "Maximum Number of Retransmissions, N2" on page II-23. 


2.%.5.2 Information Transfer Phase 


Stations, having transmitted a UA response to an received SABM command or having 
received a UA response to a transmitted SABM command, accept and transmit I and 
S-frames according to the procedures described in "Procedures for Information Transfer 
(Text deleted)" on page II-17. 
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Upon receipt of an SABM command, a UA response or a DM response with 'F=0', while in 
the information transfer phase, IBM SNA X.25 DTEs conform to the resetting procedure 
described in "Procedures for Resetting (LAPB)" on page II-20. 


When receiving an SABM command while in the information transfer phase, DCEs will 
conform to the resetting procedure described in "Procedures for Resetting CLAPB)" on 
page II-20. 


2.4.5.3 Link Disconnection 


During the information transfer phase, stations indicate disconnecting of the link by 
transmitting a DISC command across the DTE/DCE interface. 


Upon receipt of a DISC command, receiving stations return a UA response and enter the 
disconnected phase. 


DTEs wishing to disconnect the link transmit a DISC command with 'P=1' and start timer 
Tp Csee "Time-Outs and Time-Limits™ on page IJI-22). Upon receipt of a UA response with 
"F=1' from the DCE, DTEs stop timer Tp. 


Upon expiration of timer Tp prior to receipt of an appropriate response with 'F=1', 
IBM SNA X.25 DTEs perform the retransmission procedure described in "Time-Outs and 
Time-Limits™ on page II-22 before declaring the link (station) to be inoperative and 
reporting the condition to a higher layer. 


Should the DCE wish to disconnect the link, it will send the DISC command and start 
Timer Tl (Csee "Time-Outs and Time-Limits™ on page II-22. Upon receipt of the UA 
response from the DTE, the DCE will stop Timer Tl. 


Should Timer T1 expire before reception of the UA response from the DTE, the DCE will 
retransmit the DISC command and restart Timer Tl. After transmission of the DISC 
command N2 times by the DCE, appropriate recovery action will be initiated. The value 
of N2 is defined in "Maximum Number of Retransmissions, N2" on page II-23. 


2.4.5.% Disconnected Phase 


1. Stations, having received a DISC command and returned a UA response, or having 
received a UA response to a transmitted DISC command, enter the disconnected 
phase. 


Stations, in the disconnected phase, may initiate link set-up. While in the 


disconnected phase, stations react to the receipt of SABM commands as described in 
"Link Set-up” on page II-15 and respond DM received DISC commands. 


pon receipt of any command frame Cother than SABM) with 'P=1', receiving stations 
respond DM with 'F=1'. 


Upon receipt of a DM with "F=0", DTEs may transmit an SABM command with 'P=1". 
Other frames are ignored by receiving stations while in the disconnected phase. 


2. When the DCE enters the disconnected phase after detecting error conditions as. 
listed in "Rejection Conditions (LAPB)" on page II-21, or exceptionally after 
recovery from a temporary internal malfunction; it may also indicate this by 
sending a DM response rather than a DISC command. In these cases, the DCE will 
transmit DM and start timer Tl Csee "Time-Outs and Time-Limits”™ on page II-22). 


If timer Tl runs out before the reception of an SABM or DISC command from the DTE, 
the DCE will retransmit the DM response and restart timer Tl. After transmission 
of the DM response N2 times, DCES remain in the disconnected phase and initiate 
appropriate recovery actions. The value of N2 is defined in "Maximum Number of 
Retransmissions, N2" on page II-23. 
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2.4.5.5 Collision of Unnumbered Commands 
Collision situations are resolved in the following manner. 


1. Like Commands when the sent and received U commands are the same, receiving 
stations both send a UA response at the earliest possible opportunity. Stations 
enter the indicated phase upon receipt of the UA response. 


2. Unlike Commands when the sent and received U commands are different, receiving 
stations both enter the disconnected phase and transmit a DM response at the 
earliest possible opportunity. 


2.4.5.6 Collision of a DM Response With a SABM or DISC Command 


When a DM response is issued by the DCE as an unsolicited response to request the DTE 
to issue a mode-setting command, as described in "Disconnected Phase" on page II-16, a 
collision between the SABM or DISC command issued by the DTE and the unsolicited DM 
response issued by the DCE may occur. IBM SNA X.25 DTEs always transmit SABM and DISC 
commands with 'P=1' to avoid misinterpretation of such unsolicited DM responses. 


2.4.6 Procedures for Information Transfer (Text deleted) 


These procedures apply to the transmission of I-frames in each direction of 
transmission during the information transfer phase. 


In the following text, "number one higher™ is in reference to a continuously repeated 
sequence series, i.e., '7" is one higher than "6" and '0" is one higher than '7' for 
modulo eight series. 


2.4.6.1 Sending I Frames 


Stations having I-frames to transmit Ci.e., I-frames not already transmitted, or 
having to be retransmitted as described in "Receiving Reject™ on page [I-19 or 
"Waiting for Acknowledgement" on page II-19, transmit them with an Ns equal to the 
current value of Vs at the transmitting station, and an Nr equal to the current value 
of Vr at the transmitting station. Upon completion of transmission of each successive 
I-frame, transmitting stations increment Vs by one (1). 


DCEs start timer T1 if it is not running at the instant of transmission of an I-frame. 


IBM SNA X.25 DTEs must start timer Tp upon completion of transmission of I-frames if it 
1s not already running. 


When the value of Vs at a transmitting station is equal to the last value of Nr 

received from the remote station plus 'K' (where 'K' is the maximum permissible number 

of outstanding I-frames allowed - see "Maximum Number of Outstanding I-frames, K" on 

page II-23), stations do not transmit any new I-frames, but may retransmit I-frames as 

sh aoe in "Receiving Reject™ on page II-19 or "Waiting for Acknowledgement” on page 
-19. 


Note: To ensure integrity of information transfer, stations do not transmit any 
I-frames when Vs at the transmitting station is equal to the last value of Nr received 
from the remote station plus '7'. 


Stations in the busy condition may continue to transmit I-frames,» provided the remote 


station is not also in a busy condition. (Text deleted). Stations in the frame 
rejection condition, do not transmit I-frames. 
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2.4.6.2 Receiving I-Frames 


1. Correct Receipt 


Upon receipt of an I-frame with the correct FCS and an Ns equal to the current 
value of Vr at the receiving station, stations not in the busy condition accept 
the I-field, increment the value of Vr by one (1) and acknowledge receipt of the 
I-frame(s) by transmitting: 


a. the next sequential I-frame to be transmitted, if available, or an RR 
supervisory frame with an Nr equal to the current value of Vr; or, 


b. an RR supervisory frame with an Nr equal to the current value of Vr, if no 
I-frame is available for transmission. | 


2. Busy 


DCEs may ignore the information field contained in I-frames received while in a 
busy condition. | 


DTEs tgnore the information field contained in I-frames received while in a busy 
condition. 


Note: Zero length information fields shall not be passed to the packet level by the’ 
DCE and this situation should be indicated to the packet level. 


IBM SNA X.25 DTEs treat I-frames with zero length information fields the same as any 
other I-frame at ne link level. 


2.4.6.3 Receipt of Incorrect Frames 


Frames with an tncorrect FCS; an unknown address and invalid frames (see "Invalid 
frames" on page II-5) are ignored by receiving stations. 


Stations receiving I-frames with the correct FCS, but with an incorrect Ns Ci.e., one 
that is not equal to the current value of Vr at the receiving station) discard the 
I-field and transmit a REJ response with an Nr one higher than the Ns contained in the 
last correctly received I-frame. Then they discard the I-field, but use the Nr and 'P* 
bit indications of all I frames received with an Ns that is not equal to the current 
value of Vr at the receiving station. Upon receipt of the expected I-frame (i.e., one 
With an Ns equal to the current vaiue of Vr), receiving stations acknowledge the frame 
as described in "Receiving I-Frames."™ 


2.4.6.% Receiving Acknowledgement 


DTEs, even in a busy condition (text deleted), consider the Nr contained in correctly 
received [I or S CRR, RNR and REJ) frames to be an acknowledgement for all I-frames 
transmitted with an Ns up to and including 'Nr-1'. 


IBM SNA X.25 DTEs reset timer Tp upon correct receipt of an I or S-frame that actually 
acknowledges some previously transmitted I-frame(s) (i.e., a frame with an Nr higher 
than the value of the last Nr received); or, upon receipt of an I or S-frame with 
Tro] , ; 


If timer Tp has been reset with I-frame(s) still unacknowledged, DTEs restart timer 
Tp. If timer Tp expires prior to receipt of an acknowledgment, DTEs follow the 
retransmission procedure described in "Receiving Reject" on page II-19 and "Waiting 
for Acknowledgement" on page II-19 with respect to the unacknowledged I-frame(s). 


When correctly receiving an I or S~-frame (RR, RNR or REJ), even in the busy (text 
deleted) condition, DCEs consider the Nr contained in this frame as an acknowledgment 
for all the I-frames they have transmitted with an Ns up to and including the received 
Nr minus one. The DCE will reset timer Ti when it correctly receives an I or S-frame 
with the Nr higher than the last received Nr Cactually acknowledging some I-frame(s)). 
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If, timer Tl has been reset, and if there are outstanding I-frames”) still 
unacknowledged, the DCE will restart timer Tl. If timer Tl then runs out, the DCE will 
follow the retransmission procedure Cin "Receiving Reject" on page II-19 and "Waiting 
for Acknowledgement" on page II-19) with respect to the unacknowledged I-frames. 


2.4.6.5 Receiving Reject 


Upon receipt of a REJ frame, receiving stations set Vs equal to the Nr contained in the 
received REJ frame, then transmit the corresponding I-frame when it is available or 
retransmit it. 


Stations conform to the following with respect to the re-transmission of I-frames: 


1. A station that is transmitting a supervisory or unnumbered command or response 
when it receives a REJ, will complete the transmission in progress’ before 
commencing transmission of the requested I-frame. 


2. A station that is transmitting an I-frame when a REJ is received, may abort 
transmission of the I frame and commence transmission of the requested I-frame 
immediately after abortion. 


3. A station that is not transmitting any frame when a REJ is received, commence 
transmission of the requested I-frame immediately: 


Other unacknowledged I-frames already transmitted, following the one indicated in the 
REJ- are retransmitted following retransmission of the requested I-frame. 


If the REJ frame was received from the remote station as a command with '‘P=1', 
receiving stations transmit an RR or RNR response with 'F=1' prior to transmitting or 
retransmitting the corresponding I-frame. 


2.4.6.6 Receiving RNR 


After receiving an RNR, stations may transmit or retransmit the I-frame with Ns equal 
to the Nr indicated in the RNR frame received. If timer Tl Cor Tp for DTEs) runs out 
after the reception of RNR, stations follow the procedure described in "Waiting for 
Acknowledgement." Stations do not transmit any other I-frames after receipt of an RNR 
frame until an RR or REJ frame 15 received from the remote station. 


2.4.6.7 Station Busy Condition 


Stations experiencing a busy condition transmit an RNR command or response at the 
earliest opportunity. While tn the busy condition, stations accept and process 
S-frames and respond RNR with 'F=1' to I and S command frames received with 'P=1'. To 
clear a busy condition, stations transmit either REJ commands or responses or RR 
commands or response with Nr set to the current value of Vr, depending on whether or 
not information fields of correctly received I-frames were discarded. 


Note: DTEs encountering DCE busy conditions, may transmit supervisory command frames 
with "P=1' to solicit the status of the DCE. DTEs that do not implement supervisory 
commands, may use the procedures Capplicable to LAPB) for DCEs described in "Receiving 
RNR." 


2.4.6.8 Waiting for Acknowledgement 


Transmitting stations maintain an internal retransmission count CY) which is set to 
"0" upon receipt of a UA or RNR, or upon correct receipt of an I or S-frame with an Nr 

ayer than the last Nr received from the remote station Cactually acknowledging some 
~frame(s)). my 
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If Timer Tl Cor Tp for DTEs) expires, stations enter or (re-Jenter the timer recovery 
ache ari increment 'Y* by one (1) and set an internal variable (X) to the current 
value of Vs. 


Stations restart timer Tl (or Tp for DTEs), set Vs equal to the value of the last Nr 
received from the remote station and retransmit the corresponding I-frame with 'P=1' 
or transmit an appropriate S-frame with 'P=1'. 


Timer recovery conditions are cleared upon receipt of a valid S-frame with 'F=1'. 


Upon correct receipt of a supervisory frame with "F=1" and an Nr within the range from 
the current value of Vs to 'X' included, stations clear the timer recovery condition 
and set Vs equal to the value of Nr received. 


Upon correct receipt of a supervisory frame with 'F=0" and with an Nr within the range 
from the current value of Vs to 'X' included, stations do not clear the timer recovery 
condition. The received Nr may be used to update Vs. However, stations may retransmit 
the last retransmitted I-frame Ceven if it is acknowledged) with "P=1' in the event 
that timer Tl Cor Tp for DTEs) expires at a later time. | 


When "Y' is equal to N2 Cor Np for DTEs), stations initiate a resetting procedure as 


described in (text deleted) "Procedure" or "Alternative #17 on page II-21. The values 


of N2 Cand Np for DTEs) are system parameter (see "Maximum Number of Retransmissions, 
N2" on page II-23). 


Note: Although DCEs implement the internal variable '"X', other mechanisms exist that 
achieve the identical functions. Therefore, internal variable (X) is not necessarily 
implemented in all DTEs. 


2.4.7 Procedures for Resetting (LAP) 


(Text deleted). 


Unbalanced Link Access Procedures (LAP) are not allowed in SNA environments. 


2.4.8 Re-2ction Conditions (LAP) 


(Text deleted). 


Unbalanced Link Access Procedures (LAP) are not allowed in SNA environments. 


2.4.9 Procedures for Resetting (LAPB) 


2.4.9.1 Introduction 


The resetting procedures described here are used, only during the information transfer 
phase, to initialize/reinitialize both directions of information transmission. 


2.4.9.2 Procedure 


Stations indicate a resetting by transmitting a SABM command. Upon receipt of a SABM 
command, receiving stations prepared to resume normal link level operation return a UA 
response, at the earliest opportunity, and set Vs and Vr equal to '0'. This also 
clears station busy conditions, if present. DTEs not prepared to resume normal link 
level operations upon receipt of a SABM command transmit a DM response and enter the 
disconnected phase. Prior to initiating this link resetting procedure, stations may 
initiate a disconnect procedure as described in "Link Disconnection" on page II-16. 
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2.4.9.3 Alternative #1 


Under certain rejection conditions listed in "Waiting for Acknowledgement" on page 
II-19 and "Unsolicited DM or FRMR"™ on page II-22, DCEs may ask the DTE to reset the 
link by transmitting a DM response. 


After transmitting a DM response, DCEs enter the disconnected phase as described in 
item #2 under "Disconnected Phase” on page II-16. 


Upon receipt of a DM response with 'F=0"', DTEs prepared to resume normal link layer 
operations may transmit a SABM command with 'P=1' and start timer Tp. 


(Text deleted). 


2.4.9.4 Alternative #2 


Under certain rejection conditions listed in "Erroneous Frame,™ stations may request 
the remote station to reset the link by transmitting a FRMR response. 


After transmitting a FRMR response, transmitting stations enter the frame rejection 
condition. The frame rejection condition is cleared when the station receives a SABM 
or DISC command or a DM response. Other commands received while in the frame rejection 
condition cause receiving stations to retransmit the FRMR response with the same 
information field originally transmitted. 


Upon receipt of a FRMR response, DTEs prepared to resume normal link layer operations 
transmit an SABM command with ‘"P=1'" and start timer Tp. Otherwise, DTEs initiate the 
disconnect procedure described in "Link Disconnection™ on page IJI-16. 


Note: If unacknowledged frames are purged, by the DTE or DCE, as a result of 
resetting the link layer, notification must be given to a higher layer to protect the 
integrity of the system. 


DCEs may start timer T1 on transmission of the FRMR response. If timer Tl then expires 
prior to the receipt of an SABM or DISC command from the DTE, DCEs may retransmit the 
FRMR response and restart timer T1. After transmission of the FRMR response N2 times 
DCEs may reset the link as described itn "Procedure" on page II-20. The value of N2 is 
defined in "Maximum Number of Retransmissions, N2" on page II-23. 


2.4.10 Rejection Conditions (LAPB) 


2.%.10.1 Erroneous Frame 


Stat’ons initiate a resetting procedure as described in “Alternative #2," upon 
receipt, during the information transfer phase, of a frame with the correct FCS, with 
the address ‘'A'* or ‘'B’*, and with one of the following conditions: 


e the frame is unknown as a command or as a response; 
@ the information field is invalid; or, 
e the frame contains an tnvalid Nr as defined in "CText deleted); Frame Reject 


CFRMR) Response" on page IJI-1l. 
Coding of the information field of FRMR responses transmitted is given in "(Text 
deleted); Frame Reject CFRMR) Response™ on page IJI-11. Bit 13 of this information 
fieid is set to: 


"O' 3f the rejected frame was a command; or, 
‘1’ if the rejected frame was a response. 
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2.4.190.2 Unsolicited DM or FRMR 


Stations initiate a resetting procedure as described in "Procedure" on page II-20 (Cor 
"Alternative #1" for DCEs) upon receipt, during the information transfer phase, of a 
DM response or a FRMR response. 


2.4.10.3 Unsolicited UA or ‘'F=1'* 


Stations may initiate a resetting procedure as described in "Procedure" on page II-20 
Cor "Alternative #1" on page II-21 for DCEs) upon receipt, during the information 
transfer phase a UA response or an unsolicited response with 'F=1'. 


2.4.11 List of System Parameters 


The system parameters are as follows: 


2.4.11.1 Time-Outs and Time-Limits 


1. DCE Timer, Tl 


The period of timer T1 takes into account whether the timer is started at the 
beginning or at the end of transmission of the frame at the DCE. 


The period of timer Tl, at the expiration of which retransmission of a frame may be 
initiated according to the procedures described in "Procedure for Link Set-Up and 
Disconnection CLAP)" on page II-15 to "Procedures for Information Transfer (Text. 
deleted)" on. page II-17, is a system parameter agreed upon for a period of time 
with the network Administration. 


Proper operation of the procedure requires that timer Tl be greater than the 
maximum time between transmission of frames (SABM, DM, DISC, FRMR, I-frames or 
supervisory command frames) and receipt of the corresponding response frame 
returned as an answer to this frame CUA, DM or acknowledging frame). Therefore, 
DTEs should not delay the response or acknowledging frame returned to the above 
frames by more than a value T2 less than Tl, where T2 is a system parameter. 


DCEs will not delay response or acknowledging frames by more than T2. 
2. DTE Tame-Out Function, CFt) 
The duration of the time-out function CFt) is: 
Ft = (TpeNptTd)eNd 
where: 

Tp is a function of the time allowed by DTEs between the trans- 
mission of command frames and receipt of the corresponding ack- 
nowledging frame. Upon expiration of timer Tp, DTEs retransmit 


the command with 'P=1' and restart timer Tp. 


Np 2"°1" is the maximum number of transmissions and retransmis~ 
sions of a frame follewing the expiration of time Tp. 


Td is typically many time greater than time Tp and 1s the time 
to be delayed between consecutive repetitions of TpeNp. 


Nd 2°'1' is the maximum number of repetitions of TpeNptTd to be 
performed befcre declaring the link/station to be inoperative. 


Note: Although Td may be defined as zero, experience has shown that when Td='0° 


and WNd='1' are used, links are often declared inoperative prematurely, causing 
unnecessary session outages and user dissatisfaction. 
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It is, therefore, recommended that Tp, Np, Td and Nd have default values that can 
be overridden by customers as experience indicates. 


IBM SNA X.25 DTEs start timer Tp upon completion of transmission of. supervisory 
command frames or I-frames with 'P=1L"'. 


3. Time-Limit, T2 


Time-limit T2 is the maximum time allowed between receipt of command frames from 
remote stations and transmission of the appropriate response frames. This value 
1s product and configuration specific. T2 must never exceed the time needed to 
transmit-one maximum length frame plus fifty (50) milliseconds. 


2.4.11.2 Maximum Number of Retransmissions, N2 


The value of the maximum number of transmissions and retransmissions of a frame 
following the expiration of timer Tl is a system parameter (N2) agreed upon for a 
pertod of time with the network Administration. 


2.4.11.3 Maximum Number of Bits in an I-frame, Nl 


The maximum permissible number of bits in an I-frame, exclusive of bits inserted for 
transparency, is a system parameter (N1) which depends upon the maximum length of the 
information fields transferred across the DTE/DCE interface Ci.e., 48+(8 times the 
maximum number of octets allowed tn the information field of I-frames)). 


2.4.11.4 Maximum Number of Outstanding I-frames, K 


The maximum permissible number (CK) of sequentially numbered I-frames that stations may 
have outstanding Ci.e., unacknowledged) at any given time 15 a system parameter which 
can never exceed seven (7). The value of 'K’ 1s agreed upon for a period of time with 
the network Administration. It is essential that 'K' be a parameter whose default 
value can be overridden. 


Note: As a result of the further study proposed in "Control (C) Field” on page II-4, 
the permissible maximum number of outstanding I-frames may be increased by the CCITT. 


2-4.11.5 DTE Timer, Ti 


The period of time that the DTE may allow the link to be itn the idle channel state 
before considering it to be itn the disconnected phase Cout-of-order) state. Ti is 
much larger Tp. 


2.5 MULTI-LINK PROCEDURE 


CCITT Recommendation X.25 (1984) defines formats and procedures for the operation of 
multiple parallel data links between DTEs and DCEs for a given DTE/DCE interface 
appearance. However, this and other additional capabilities defined in CCITT 
Recommendation X.25 (1984) are being evaluated to ascertain their applicability in SNA 


environments and decisions regarding support in IBM SNA X.25 DTEs will be based on 


future technical and business considerations. 
It is, therefore, recommended that LAPB be implemented in such a manner that 


compatibility with the multi-link procedure described in CCITT Recommendation X.25 
(1984) can be maintained. 3 | 
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3.0 DESCRIPTION OF THE PACKET LEVEL DTE/DCE INTERFACE 


This and subsequent points relate to the transfer of packets at the DTE/DCE interface 
for both SNA-to-SNA connections and for SNA-to-non SNA connections. The procedures 
apply to packets that are successfully transferred across the DTE/DCE interface. 


Packets transferred across the DTE/DCE interface are contained within the link level 


information field which delimit their length, and only one packet is contatned within | 


the information field. 


Note: 
1. (Text deleted). 


2. At present, some networks require the data fields of packets to contain an 
integral number of octets. The transmission by the DTE of data fields not 
containing an integral number of octets to networks may cause a loss of data 
integrity. 


DTEs wishing universal operation on all networks should transmit packets with data 
fields containing only an integral number of octets. Full data integrity can only be 
assured by exchange of octet-oriented data fields tn both directions of transmission. 


IBM SNA X.25 DTEs transmit and receive sdckebs with User Data fields that contain an 
integral number of octets only. 


This point covers a description of the packet level interface for virtual call and 
permanent virtual circuit services (text deleted). As designated in Recommendation 
X.2 (€2], virtual call and permanent virtual circuit services are essential (E) 
services to be provided by all networks. (Text deleted). 


Note: Under study by the CCITT are considerations regarding the amount of duplication 
between datagram, fast select and possible additional virtual call enhancements with 
the objective to minimize the variety of interfaces. 


For SNA-to-SNA connections, virtual circuits (virtual calls or permanent virtual 
circuits) are treated, by SNA DTEs, as real links that can accommodate multiple SNA 
sessions. Permanent virtual circuits are managed like non-switched links while 
virtual calls are managed either like switched links or like non-switched links 
depending upon the implementation at the IBM SNA X.25 DIE. Except for the IBN-5973 
Network Interface Adapter (NIA), IBM SNA X.25 DTEs must use 'Qualified’ data packets 
for Logical Link Control (Q@LLC) or the Enhanced Logical Link Control CELLC) to perform 
adjacent SNA node physical services (see “Logical Link Control (LLCO) on SNA-to- SNA 
Connections™ on page II-83). Adjacent SNA node physical services, segmentation and 
sequence numbering may be performed with an optional Physical Services Header (PSH) as 
described in Appendix H only for compatibility with the IBM-5973 NIA. 


For SNA-to-non SNA connections, transformation between X.25 and SNA protocols may be 
performed at SNA boundary network nodes. In this environment several implementation 
approaches can be used as described in Appendix I. : 


SNA-to-SNA connections and SNA-to-non SNA connections differ only at the packet level. 
Thus, the previous points ("DTE/DCE Interface Characteristics - (physical level)" on 
page JI-1l and "Link Access Procedure across the DTE/DCE Interface" on page II-3) apply 
equally to both types of connection. Functions, facilities, formats and procedures in 
"DESCRIPTION OF THE PACKET LEVEL DTE/DCE INTERFACE,™ "PROCEDURES FOR VIRTUAL CIRCUIT 
SERVICES" on page II-29, "Procedures for Datagram Service" on page II-45, "PACKET 
FORMATS” on page II-46 and “PROCEDURES AND FORMATS FOR OPTIONAL USER FACILITIES” on 
ile ae 69 that apply only to SNA-to-non SNA connections are enclosed in brackets 
q., tLtext]) 


(Text deleted). 


Procedures for virtual circuit service (Ci.e., virtual call and permanent virtual 
circuit services) are specified in "PROCEDURES FOR VIRTUAL CIRCUIT SERVICES” on page 
II-29. (Text deleted). Packet formats for virtual circuit services are specified in 
"PACKET FORMATS” on page II-46. Procedures and formats for optional user facilities 
are specified in "PROCEDURES AND FORMATS FOR OPTIONAL USER FACILITIES" on page II-69. 
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3-1 LOGICAL CHANNELS 


To enable simultaneous virtual calls and/or permanent virtual circuits (text deleted), 
logical channels are used. Each virtual call and permanent virtual circuit is 
assiqned a Logical Channel Group Number (Cless than or equal to 15) and a Logical 
Channel Number (less than or equal to 255). For virtual calls, a Logical Channel Group 
Number and a Logical Channel Number are assigned during the call set-up phase. The 
range of logical channels used for virtual calls is agreed upon with the network 
Administration at the time of subscription to the service (see Appendix A). For 
permanent virtual circuits (text deleted), Logical Channel Group Numbers and Logical 
Channel Numbers are assigned in agreement with the Administration at the time of 
subscription to the service (see Appendix A). 


The Logical Channel Group Number and the Logical Channel Number may be managed as a 
single twelve-bit entity (Logical Channel Identifier - LCI). 


3.2 BASIC STRUCTURE OF PACKETS 


Packets transferred across the DTE/DCE interface consist of at least three octets. 
These three octets contain a general format identifier (GFI), logical channel 
identifier (LCI) and a packet type identifier (PTI). Other fields are appended to 
packets as required (see "PACKET FORMATS" on page II-46). 


Packet types and their use in association with various services are given in Table 
II-5. 
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TABLE II-5 — Packet Types and Their Uses in Various Services 


PACKET TYPE | SERVICE | Mnemonic | 


CALL SET-UP AND CLEARING 


INCOMING CALL CALL REQUEST 
CALL CONNECTED CALL ACCEPTED 
CLEAR INDICATION CLEAR REQUEST 


o<0 
TNH 
Mow 
mag 


DCE CLEAR CONFIRMATION DTE CLEAR CONFIRMATION 
DATA CAND INTERRUPT] 


DCE DATA DTE DATA 
[DCE INTERRUPT] CDTE INTERRUPT] 
CDCE INTERRUPT CDTE INTERRUPT 


CGNFIRMATICN] CONFIRMATION] 


FLOW CONTROL AND RESET 
DCE RR DTE RR X X NRR TRR 
DCE RNR DTE RNR X X NNR TNR 
RESET INDICATION X X RSI 
RESET REQUEST X RSR 
DCE RESET CONFIRMATION DTE RESET CONFIRMATION X NRC TRC: 


RESTART 
RESTART INDICATION RESTART REQUEST 
DCE RESTART CONFIRMATION DTE RESTART CONFIRMATION 


DIAGNOSTIC Te Per 


Virtual Call 
Permanent Virtual Circuit 
Entire DTE/DCE Interface 


aoe 
ZH 
7 
Or 
“ie 
ww 
Qn 


pve 
ITF 


¥% 


Not necessarily available on all networks. 
Note: DTE REJ and DATAGRAM packets are not used. 
Text deleted. 


The restart procedure is used to initialize or reinitialize the packet level DTE/DCE 
interface. The DTE restart procedure must be executed after link level initialization 
1s complete. The DTE/DCE interface becomes operational only upon. successful 
completion of the restart procedure. The restart procedure simultaneously clears all 
virtual calls and resets all permanent virtual circuits (text deleted) at the DTE/DCE 
interface (see "Effects of Clear, Reset and Restart Procedures on the Transfer of 
Packets" on page II~-43( text deleted)). 


Figure B-1, in Appendix B, gives the state diagram which defines the logical 
relationships of events related to the restart procedure. 


Table C-2, in Appendix C, specifies actions taken by DCEs upon receipt of packets from 
DTEs for the restart procedure. (Text deleted). 


Table G-2, in Appendix G, specifies the actions taken by DTEs on receipt of packets 
from DCEs for the restart procedure. 


3.3.1 Restart by DTEs 


At any time, after link level initialization is complete, DTEs may initiate a restart 
by transferring a RESTART REQUEST packet across the DTE/DCE interface. The Diagnostic 
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Code field in RESTART REQUEST packets is coded x'00' to indicate initial restart (see 
Appendix F for SNA-to-SNA connections). The interface for each logical channel is 
then in the DTE RESTART REQUEST state (r2). 


DCEs confirm restart by transferring a DCE RESTART CONFIRMATION packet placing logical 
channels used for virtual calls in the READY state (pl), and logical channels used for 
permanent virtual circuits (text deleted) in the FLOW CONTROL READY state (d1). 


Note: States pl and dl are specified in "PROCEDURES FOR VIRTUAL CIRCUIT SERVICES” on 
page ITI-29 (text deleted). 


DCE RESTART CONFIRMATION packets can only be interpreted universally as having local 
significance. The time spent in the DTE RESTART REQUEST state (r2) will not exceed 
time-limit T20 (see Appendix D). In this state, DTEs ignore all packets, except 
RESTART INDICATION and DCE RESTART CONFIRMATION. If the DCE does not confirm this 
restart within 200 seconds, the RESTART REQUEST packet can be retransmitted after the 
200 second timer its reinitialized. If the total time spent in state (r2) exceeds 'n' 
times 200 seconds, where 'n21', notification of failure of the DIE/DCE interface must 
be reported to a higher level by IBM SNA X.25 DTEs using the Diagnostic code x'34°'., 
The DTE/DCE interface must be placed in an inoperative state. 


Note: [For SNA-to-non SNA connections the coding of the diagnostic field is a matter 
to be negotiated by the specific non-SNA DTEC(s).] 


3.3.2 Restart by DCEs 


DCEs may indicate a restart by transferring a RESTART INDICATION packet across the 
DTE/DCE interface. The interface for each logical channel is then in the DCE RESTART 
INDICATION state (r3). In this state of the DTE/DCE interface, DCEs ignore all 
packets except RESTART REQUEST and DTE RESTART CONFIRMATION. IBM SNA X.25 DTEs must 
report the contents of the restart cause and diagnostic fields contained in RESTART 
INDICATION packets to a higher layer. 


DTEs confirm the restart by transmitting a DTE RESTART CONFIRMATION packet across the 
DTE/ZDCE interface, before timer T10 elapses, placing all logical channels used for 
virtual calls in the READY state (pl) and all logical channels used for permanent 
virtual circuits (text deleted) in the FLOW CONTROL READY state (dl). 


Actions taken by DCEs when DTEs do not confirm the restart within time-out T10 are 
given in Appendix D. 


3.3.3 Restart Collision 


Restart collision occurs when a DTE and a DCE simultaneously transfer a RESTART 
REQUEST and a RESTART INDICATION packet. When this occurs, DCEs consider the restart 
to be complete. DCEs do not expect a DTE RESTART CONFIRMATION packet and do not 
transfer a DCE RESTART CONFIRMATION packet. DTEs do not expect a DCE RESTART 
CONFIRMATION packet and do not transfer a DTE RESTART CONFIRMATION packet when a 
restart collision occurs. This places all logical channels used for virtual calls in 
the READY state (pl), and all logical channels used for permanent virtual circuits 
(text deleted) in the FLOW CONTROL READY state (dl). 


3.4 ERROR HANDLING 


Table C-1, in Appendix C, specifies the reaction of DCEs when special error conditions 
are encountered. Other error conditions are discussed in §-4. (Text deleted). Table 
G-1, in Appendix G, specifies the reaction of DTEs when special error situations are 
encountered. 
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3.4.1] Diagnostic Packet 


DIAGNOSTIC packets are used by some networks to indicate error conditions in 
circumstances where the usual methods of indication (i.e., reset, clear and restart 
with cause and diagnostic) are not appropriate (see Tables C-1 and D-1). DIAGNOSTIC 
packets from DCEs supply information on error situations that are considered to be 
unrecoverable at the packet level of X.25; the information provided in the diagnostic 
code and explanation fields of DIAGNOSTIC packets must be reported to a higher level 
for error analysis and recovery by IBM SNA X.25 DTEs. No state transition takes place 
on the logical channel to which the DIAGNOSTIC packet is related. 


A DIAGNOSTIC packet is issued only once per particular instance of an error condition. 
DTEs do not confirm receipt of DIAGNOSTIC packets. After issuing a DIAGNOSTIC packet, 
DCEs maintain the logical channel(s) to which the DIAGNOSTIC packet is related in the 
same state as that when the DIAGNOSTIC packet was generated. 


3.5 EFFECTS OF THE PHYSICAL LEVEL AND THE LINK LEVEL ON THE PACKET LEVEL 


Changes in operational states at the physical level and the link level of the DITE/DCE 
interface do not implicitly change the state of logical channels at the packet level. 
When such changes occur, they are explicitly indicated at the packet level by the use 
of appropriate clear, reset or restart procedures. 


Failures at the physical and/or link level are conditions tn which stations cannot 
transmit and receive any frames because of abnormal conditions caused by, for 
instance, a line fault between the DTE and the DCE. 


When failures at the physical level or the link level are detected, virtual calls are 
cleared and permanent virtual circuits are declared out of order (text deleted) by 
DCEs. Further actions are specified in "Effects of Physical and Link Level Failures" 
on page II-4%4 for virtual circuit services (text deleted). 


When DTEs detect such a failure, or when the link goes into disconnected mode, and link 
level queues are purged by the DTE or the DCE, inoperative notifications must be given 
to higher levels. In this event, inoperative notification are required for the LAPB 
link and for all virtual circuits to cause all using SNA half-sessions to be notified 
of the outage. 


When physical and/or link level failures are recovered, DCEs transmit RESTART 
INDICATION packets with the cause "Network Operational™ to local DTEs. Further 
actions are specified in "Effects of Physical and Link Level Failures” on page II-44% 
for virtua: circuit services (text deleted). 


(Text deleted). 

In other out-of-order conditions at the physical and/or link level, including 
transmission of a DISC command by the DTE, the behavior of the DCE 1s being studied by 
the CCITT. 


IBM SNA X.25 DTEs assume that DCEs clear virtual calls and reset permanent virtual 
circuits when other out of order conditions occur at the physical and/or link level. 


Note: An out-of-order condition on the link level includes receipt of a DISC commands 
by DCEs in the case of a single link procedure. 


(Text deleted). 
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4.0 PROCEDURES FOR VIRTUAL CIRCUIT SERVICES. 


4.1 PROCEDURES FOR VIRTUAL CALL SERVICE 


Figures B-1, B-2 and B-3, in Appendix B, contain state diagrams which define the state 
transitions that occur at the packet level DTE/DCE interface for logical channels used 
for virtual calls. 


Appendix.C gives details of the actions taken by DCEs on receipt of packets in each 
state shown in Appendix B. 


Text deleted. 


Appendix G gives details of the actions taken by DTEs on receipt of packets in each 
state shown in Appendti~x B. 


The call set-up and clearing procedures, described in the following points, apply 
independently to each logical channel assigned to virtual call service at the DTE/DCE 
interface. 


4.1.1 Ready State 


A logical channel is in the READY state Cpl) when no call exists. 


46.1.2 Call Request Packet 


Calling DTEs indicate call requests by transferring CALL REQUEST packets across the 
DTE/DCE interface. The logical channel, selected for the call by the DTE, is then in 
the DTE WAITING state (p2). If the time spent in the DTE WAITING state (p2) exceeds 
200 seconds, the CALL REQUEST packet can be retransmitted after the 200 second timer 
is retnitialized. If the total time spent in state (p2) exceeds 'n' times 200 seconds, 
where ‘n21', a CLEAR REQUEST is transmitted and notification of the CALL REQUEST 
failure must be reported to a higher level using the Diagnostic code #49; the logical 
channel is placed in an inoperative state. CALL REQUEST packets include the called 
DTE address. The calling DTE address field may also be used. 


Note: 


1. A DTE address may be a network address, an abbreviated address or any other DTE 
identification agreed upon for a period of time between the DTE and the DCE. 


2. CALL REQUEST packets use the. logical channel in the READY state (rl) with the 
highest number in the range that has been agreed upon with the network 
Administration (see Appendix A). Thus, the risk of call collision 1s minimized. 


4.1.3 Incoming Call Packet 


DCEs tndicate incoming calls by transferring INCOMING CALL packets across the DTE/DCE 
interface. This places the logical channel, selected by the DCE for the call, tn the 
DCE WAITING state (p3). 


DCEs assign the logical channel in the READY state (rl) with the lowest number (see 
Appendix A) to INCOMING CALL packets. INCOMING CALL packets include the calling DTE 
address. The called DTE address field may also be used. The contents of the called 
DTE address field are ignored by IBM SNA X.25 DTEs. 
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Note: A DTE address may be a DTE network address, an abbreviated address or any other 
DTE identification agreed upon for a period of time between the DTE and the DCE. 


46.1.4 Call Accepted Packet 


Called DTEs accept calls by transferring CALL ACCEPTED packets, specifying the logical 
channel indicated in INCOMING CALL packets across the DTE/DCE interface, before timer 
T11 elapses. This places the specified logical channel in the DATA TRANSFER state 
(p4). 


If the called DTE does not accept a call by transmitting a CALL ACCEPTED packet, or 
does not reject it by transmitting a CLEAR REQUEST packet as described in "Clearing by 
DTEs,™ within time-out T1l1l (see Appendix D), DCEs consider this to be a procedure 
error on the part of the called DTE and clear the virtual call according to the 
procedure described in "Clearing by DCEs"”™ on page II-3l. 


4.1.5 Call Connected Packet 


Receipt of a CALL CONNECTED packet specifying the logical channel assigned to a 
previous CALL REQUEST packet by a calling DTE indicates that the call has been 


accepted by the called DTE. This places the specified logical channel in the DATA 
TRANSFER state (p4). 


The time spent in the DTE WAITING state (p2) will not exceed time-limit T21 (see 
Appendix D). 


4.1.6 Call Collision 


Call collision occurs when a DTE and DCE simultaneously transfer a CALL REQUEST packet 
and an INCOMING CALL packet specifying the same logical channel. When this occurs, 
DCEs proceed with the call request and cancel the incoming call. DTEs discard the 
INCOMING CALL packet in the event of call collision. 


4.1.7 Clearing by DTEs 


DTEs may indicate call clearing, at any time, by transferring a CLEAR REQUEST packet 
across the DTE/DCE interface (see "Effects of Clear, Reset and Restart Procedures on 
the Transfer of Packets" on page II-43). The specified logical channel is then in the 
DTE CLEAR REQUEST state (p6). DCEs transfer a DCE CLEAR CONFIRMATION packet 
specifying the same logical channel across the DITE/DCE interface when prepared to free 
the logical channel. The logical channel is then in the READY state (pl). 


DCE CLEAR CONFIRMATION packets can only be interpreted universally as having local 
significance; however, they may have end to end significance in some networks. In any 
event the time spent in the DTE CLEAR REQUEST state (p6) will not exceed time-limit T23 
(see Appendix D). If a DCE CLEAR CONFIRMATION packet is not received within 200 
seconds, the CLEAR REQUEST packet can be retransmitted after the 200 second timer is 
reinitialized. If the total time spent in state (p6) exceeds 'n' times 200 seconds, 
where 'n21', notification of the clear failure must be given to a higher level by IBM 
SNA. X.25 DTEs using the Diagnostic code #50; the logical channel is placed in an 
inoperative state. 


Depending upon the state of the logical channel, it is possible for DTEs to receive 
other types of packets between the transfer of a CLEAR REQUEST packet and the receipt 


of the DCE CLEAR CONFIRMATION packet. Any such packets are discarded by IBM SNA X.25 
DTEs. 


Note: Calling DTEs may abort a call by clearing the cail prior to receipt of a CALL 
CONNECTED or CLEAR INDICATION packet. 
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Called DTEs may refuse an incoming call by clearing it as described in this point 
rather than transmitting a CALL ACCEPTED packet as described in "Call Accepted Packet" 
on page II-30. Called DTEs must provide the reason for refusing incoming calls by 
placing an appropriate diagnostic code (see Appendix F) in the Diagnostic Code field 
of CLEAR REQUEST packets. 


6.1.8 Clearing by DCEs 


DCEs indicate call clearing by transferring CLEAR INDICATION packets across the 
DTE/DCE interface (see "Effects of Clear, Reset and Restart Procedures on the Transfer 
of Packets" on page II-43). The specified logical channel is then in the DCE CLEAR 
INDICATION state (p7). DTEs respond by transferring a DTE CLEAR CONFIRMATION packet 
across the DTE/DCE interface, before time-out T13 elapses. The specified logical 
channel is then in the READY state (pl). DTEsS must report the contents of network 
generated call clearing cause and diagnostic fields to a higher layer. 


Actions taken by DCEs when DTEs do not confirm call clearing within time-out T13 are 
given in Appendix D. 


4.1.9 Clear Collision 


Clear collision occurs when a DTE anda DCE simultaneously transfer a CLEAR REQUEST 
packet and a CLEAR INDICATION packet specifying the same logical channel. In this 
event, DCEs consider call clearing to be complete. DCEs do not expect a DTE CLEAR 
CONFIRMATION packet and do not transfer a DCE CLEAR CONFIRMATION packet. DTEs do not 
expect a DCE CLEAR CONFIRMATION packet and do not transfer a DTE CLEAR CONFIRMATION 
packet when a clear collision occurs. This places the specified logical channel in 
the READY state (pl). 


4.1.10 Unsuccessful Call 


When a call cannot be established, DCEs transfer a CLEAR INDICATION packet specifying 
the logical channel indicated in the CALL REQUEST packet. IBM SNA X.25 DTEs must 
report the contents of network generated call clearing cause and diagnostic code 
fields to a higher level. 


6.1.11 Call Progress Signals 


DCEs are capable of transferring the clearing call progress signals specified in CCITT 
Recommendation X.96 [4], as clearing cause and/or diagnostic codes, to DTEs. 


Clearing call progress signals are carried in CLEAR INDICATION packets that terminate 
the call to which the packet refers. The method of coding CLEAR INDICATION packets 
containing call progress signals is detailed in "Clear Request and Clear Indication 
Packets™ on page II-54. IBM SNA X.25 DTEs must report all clearing call progress 
Signals to a higher level. 


6.1.12 Data Transfer State 


Procedures for the control of packets transferred between DTEs and DCEs in the DATA 
TRANSFER state (p4) are described in "Procedures for Data [Land Interrupt] Transfer" on 
page II-32. 
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4.2 PROCEDURES FOR PERMANENT VIRTUAL CIRCUIT SERVICE 


Figures B-1 and B-3, in Appendix B, contain state diagrams defining events that occur 
at the packet lavel DTE/DCE interface for logical channels assigned for permanent 


virtual circuits. 


Appendix C gives details of the action taken by oo upon receipt of packets in each 
state shown in Appendix B. (Text deleted). ‘ 


Appendix G gives details of the action taken by DTEs upon receipt of packets in each 
state shown in Appendix B. 


Call set-up and clearing procedures do not apply to permanent virtual circuits. 
Procedures for the control of packets transferred between DTEs and DCEs while in the 
SATA TRANSFER state (p4) are described in "Procedures for Data [Cand Interrupt] 
Transfer." 


§.3_ PROCEDURES FOR DATA CAN) INTERRUPT] TRANSFER. 


The data transfer [Cand interrupt] procedures described in the following points of 
"Procedures for Data [and Interrupt] Transfer" apply independently to each logical 
channel assigned for virtual calls and permanent virtual circuits existing at the 
DTE/DCE interface. 


Normal network operation dictates that user data in data [Land interrupt] packets are 
all passed transparently, unaltered through the network in the case of packet DTE to 
packet DTE communications. Order of bits in data packets is preserved. Packet 
sequences: are delivered as complete packet sequences. DTE Diagnostic Codes are 
treated as described in "Clear Request and Clear Indication Packets™ on page II-54, 
"Reset Request and Reset Indication Packets" on page II-60 and "Restart Request and 


| Restart Indication Packets" on page II-62. 


4.3.1 States for Data Transfer 


A virtual call logical channel is in the DATA TRANSFER state (p4) after completion of 


call establishment and prior to a clearing or a restart procedure. A permanent 


virtual circuit logical channel is continually in the DATA TRANSFER state (p4¢) except 
during the restart procedure. Data, Cinterrupt, ] flow control and reset packets may 
he transmitted and received by DTEs in the DATA TRANSFER state (p4) of a logical 
channel at the DTE/DCE interface. In this state, the flow control and reset 
procedures described in "Procedures for Flow Control” on page II-37 apply to data 
transmission on that logical channel to and from DTEs. 


When a virtual call is cleared, data Cand interrupt] packets may be discarded by the 
network Csee "Effects of Clear, Reset and Restart Procedures on the Transfer of 
Packets” on page II-43). In addition, data, Cinterrupt,] flow control and reset 
packets transmitted by DTEs are ignored by DCEs when the logical channel is in the DCE 
CLEAR INDICATION state (p7). 


(Text deleted. ) 


4.3.1.1 SNA-to-SNA Connections 


Logical Link Control (LLC, see "Logical Link Control (LLC) on SNA-to-SNA Connections" 
on page II-83) protocols enable IBM SNA X.25 DTE's to cope with the various situations 
that may possibly occur on SNA-to-SNA connections. 


The following actions are taken by IBM SNA X.25 DTEs to protect against possible 
packet losses: — 


1. Orderly Clearing 
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Virtual call clearing is normally initiated only upon requests from SNA control 
points which are responsible for making sure that data flows have first been 
quiesced and all sessions using the virtual circuit have been properly 
deactivated. 


2. Accidental Clearing 


When call clearing is initiated by the network, following some network detected 
error condition, the station is placed in an inoperative state, notification of 
the station outage is given to a higher level causing sessicn outage notifications 
to be propagated according to SNA mechanisms to all half-sessions that were 
sharing the virtual circuit. Inoperative stations are returned to an operational 
state only ky stimulus from some higher level SNA protocol. After the station is 
recontacted and sessions are reestablished the SNA session protocols are 
responsible for recovery from any packet loss that may have occurred as a result 
of call clearing. 


4.3.2 User Data Field Length of Data Packets 


The standard maximum User Data field length ts '128' octets. 


Other maximum User Data field lengths that may be offered by some network 
Administrations include: 


"16", "32", "64", "256", "512" and '1024" octets. 


An optional maximum User Data field length may be selected for a period of time as the 
default maximum User Data field length common to all virtual calls at the DTE/DCE 
interface (see "Non-Standard Default Packet Sizes" on page II-73). A value other than 
the default may be selected for a period of time for each permanent virtual circuit 
Csee "Non-Standard Default Packet Sizes™ on page II-73). Negotiation of maximum User 
Data fields lengths, on a per call basis, may be made with the Fiow Cerntrol Parameter 
Negotiation facility (see "Flow Control Parameter Negotiation” on page II-73). 


IBM SNA X.25 DTE implementations that allow maximum User Data field lengths other than 
"128" octets support the flow control parameter negotiation facility (1.e., not all 
networks provide the selection of a default maximum length other than '128' octets). 
As a result, a multi-channel interface may be required to simultaneously support 
multiple maxtmum packet lengths. 


The User Data field of data packets transmitted across the DTE/DCE interface may 
contain any number of octets up to the agreed maximum. 


(Text deleted. ) 


If the User Data field tn a data packet exceeds the locally permitted maximum User Data 
field length, DCEs reset the virtual call or permanent virtual circuit with the 
resetting cause "Local Procedure Error”. Upon receipt of a reset on virtual calls, 
DIEs clear the virtual call and must report the error to a higher level. 


When DTEs receive data packets that exceed the locally permitted User Data field 
length,. they clear the virtual call or reset the permanent virtual circuit with the 
diagnostic code #167, "Packet Too Long” (see Appendix F) and must report the error toa 
higher level. 


4.3.3 Delivery Confirmation (D) Bit 


4.3.3.1 SNA-to-SNA Connections 


The '"D' bit in packets on SNA-to-SNA connections should always be '0". When DTEs 
receive a data packet that contains 'D=1', they clear the virtual call or reset the 
permanent virtual circuit with the Diagnostic Code #174, "Invalid "D’ Bit Received” 
(see Appendix F) and must report the error to a higher level. 
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Upon receipt of an INCOMING CALL or CALL CONNECTED packet with 'D=1', IBM SNA X.25 DTEs 
clear the virtual call with the Diagnostic Code 'E9' (Invalid 'D* Bit Request) and 
must report the error to a higher level. 


4.3.3.2 SNA-to-non_SNA Connections 


The setting of the Delivery Confirmation (D) bit is used to indicate whether or not the 
DTE wishes to receive an erd-to-end acknowledgement of delivery, for data it is 
transmitting, by means of the packet receive sequence number (Pr) (see "Procedures for 
Flow Control" on page II-37). 


Note: 


1. Use of the 'D’' bit procedure does not obviate the need for a higher level protocol 
agreed upon between participating DTEs which may be used with or without the 'D'* 
bit procedure to recover from user or network generated resets and clearings. 


2. After January 1982, the 'D' bit procedure should be considered an integral part of 
the X.25 DTE/DCE interface. In the interim period, -the 'D' bit procedure will be 
available on some Public Data Networks and between some pairs of Public Data 
Networks ona bilateral basis. 


During the interim period, Administrations of networks that do not provide the 'D' bit 
procedure should be.consulted to determine whether the significance of Pr is a local 
updating of the wWindow across the packet level DTE/DCE interface or conveys an 
end-to-end acknowledgement of delivery of data. 


To facilitate the orderly introduction of the 'D’® bit procedures in DTEs and DCEs, the 
following mechanisms are provided. 


Calling DTEs can ascertain during call establishment that the 'D’ bit procedure can be 
used for the call by setting bit 7 in the General Format Identifier of the CALL REQUEST 
packet equal to '1' (see "General Format Identifier™ on page II-47). Every network or 
part of international network where the 'D' bit procedure is available passes this bit 
transparently. Remote DTEs able to handle the 'D’ bit procedure should not regard 
tnis bit being set to "1" in INCOMING CALL packets as invalid. 


Likewise, called DTEs can set bit 7 in the General Format Identifier of the CALL 
ACCEPTED packet equal to ‘'l'. Every network or part of tinternational network where 
the 'D' bit 1s available passes this bit transparently. Calling DTEs able to handle 
the 'D’ bit procedure should not regard this bit being set to ‘1* in CALL CONNECTED 
packets as invalid. 


If any network along the path does not support the 'D’ bit procedure, this would be 
indicated by call clearing by the DCE with a cause indicating "Incompatible 
Destination™ and the diagnostic "Invalid General Format Identifier" or by any other 
means to eee an invalid general format identifier at the DTE/DCE interface (see 
Table C-1). 


Use by DTEs of the above mechanism in CALL REQUEST and CALL ACCEPTED packets is 
recommended but is not mandatory for using the "D' bit procedure on virtual calls. 


When 'D'="1' in a data packet ona virtual call or permanent virtual circuit where the 
"D' bit procedure is not available, this will be indicated to both participating DIEs 
by a RESET INDICATION packet with the cause "Incompatible destination™ and the 
diagnostic “Invalid general format identifier"; or, by some other means to indicate an 
invalid general format identifier at the DTE/DCE interface (see Table C-1). 


DTEs may request either local or remote significance and IBM SNA X.25 DTEs' permit 
partner DTEs to operate with end-to-end significance. Thus, bit 7 of the first octet 
(GFI) in CALL REQUEST and CALL ACCEPTED packets may be set to '0' or "1' according to 
the parameters that, in the SNA "BIND"™ command opening the SNA session corresponding 
to the virtual circuit, indicate whether definite responses are supported for that SNA 
session (see Approach 1 in Appendix I). 


Similarly, the state of bit 7 of the first octet (GFI) in INCOMING CALL packets may be 


used to determine the proper "BIND" protocol. The state of bit 7 of the first octet in 
CALL CONNECTED packets may be compared to the established SNA session and a decision 


PROCEDURES FOR VIRTUAL CIRCUIT SERVICES TI-34 


SNA/X.25 DTE/DCE Interface 


made as to whether compatibility of operation on the virtual circuit and the SNA 
session is guaranteed. 


4.3.4 More Data Mark 


Stations wishing to indicate a sequence of more than one packet use a More Data mark 
C'M' bit) as defined below. 


4.3.4.1 SNA-to-SNA Connections 


"M’ bit segmenting 1s required for IBM SNA X.25 DTEs, but if compatibility with the 
IBM-5973 NIA is required, the PSH segmenting procedure described in Appendix H must be 
implemented as well. 


When PSH segmenting is implemented, the maximum packet size must be the same at the 
local and remote X.25 DTE/DCE interfaces. 


"'M=1" is only used in full data packets to indicate that more data follows. 
Recombination with the following data packet may only be performed within the network 
when ‘*M=1'. 


Two categories of data packets, 'A' and 'B’, are defined as shown in Table II-6. Table 
II-6 also illustrates the network's treatment of the "M’ bit at both ends of virtual 
calls or permanent virtual circuits. 


Upon receipt of a partially filled data packet with 'M'="1', IBM SNA X.25 DTEs on 
SNA-to-SNA connections clear the virtual call or reset the permanent virtual circuit 
with the Diagnostic Code 'Al' (Invalid 'M' Bit Packet Sequence). 


4.3.4.2 SNA-to-non_SNA Connections 


The 'M' bit can be set equal to "1" in any data packet. 'M=1" ina full data packet or 
in a partially full data packet that also has 'D=1"', indicates that more data follows. 
Recombination with the following data packet may only be performed within the network 
when '"M=1" in a full data packet that also has "D=0". 


A sequence of data packets with 'M=1' in every packet except for the last one will be 
delivered as a sequence of data packets with "M=1' in every packet except for the last 
one when the original packets having ‘'M=1" are either full Cirrespective of the 
setting of the 'D* bit) or partially full but have 'D=1"'. 


Two categories of data packets, "A’' and 'B’, are defined as shown in TABLE II-6. TABLE 


II-6 also illustrates the network's treatment of the 'M' and 'D’ bits at both ends of 
virtual calls or permanent virtual circuits. 
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Table II-6 —- Definition of Two Categories of Data Packets and Network 
Treatment of the 'M' bit and the '"D’ bit 


Data Packet 
Received b 
Destination DTE 


Combining with 
subsequent packet(s) 
1s performed by 
the network 
when possible 


Data packet sent 
by source DTE 


¥ — Refers to the delivered data packet whose last bit of user data 
corresponds to the last bit of user data, if any, that was 
present in the data packet sent by the source DTE. 

¥¥ — Valid on SNA-to-—non-SNA connections only. 


Note: If the data packet sent by the source DTE is combined with other packets, up to 
and including a category "B' packet, the 'M' and 'D’' bit settings in the data packet 
received by the destination DTE will be according to that given in the right hand 
ee for the last data packet sent by the source DTE that was part. of the 
combination. 


6.3.5 Complete Packet Sequence 


A complete packet sequence is composed of a single category '‘'B’' packet and all 
contiguous preceding category 'A* packets Cif any). Category '"A' packets have the 
exact maximum User Data field length with 'M=1" and "D=0'. All other data packets are 
category 'B' packets. 


Complete sacket sequences, transmitted by source DTEs, are always delivered to the 
destination DTE as single complete packet sequences. 


Thus, when the maximum user data field length at the receiving end is larger than that 
at the transmitting end, packets of complete packet sequences are combined within the 
network. They will be delivered as complete packet sequences where each packet, 
except the last one, has the exact maximum user data field length, 'M=1" and 'D=0". 
The User Data field of the last packet of a sequence may have less than the maximum 
length with the 'M' and '"D' bits set as described in Table II-6. 


When the maximum user data field length is the same at both ends, data fields of data 
packets are delivered to the receiving DTE exactly as received by the network, except 
as follows. If a full packet with "M=1" and 'D=0" is followed by an empty packet, the 
two packets may be merged so as to become a single category 'B' full packet. If the 
last packet of a complete packet sequence transmitted by the source DTE has a User Data 
field less than the maximum length with "M=L' and 'D=0', the last packet of the 
complete packet sequence 1s delivered to the destination DTE with 'M=0°. 


When the maximum user data field length at the receiving end is smaller than that at 


the transmitting end, packets will be segmented within the network, and the 'M' and 
"D' bits set by the network as described to maintain complete packet sequences. 
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4.3.5.1 SNA-toO-SNA Connections Only 


When PSH segmenting 1s used, the maximum packet length at the local and remote DTE/DCE 
interfaces 1s the same. Therefore, no ‘'M' bit packet sequences occur at either 
DIE/DCE interface. 


4.3.6 Qualifier Bit 


Complete packet sequences may be transmitted on one of two levels. DTEs wishing to 
transmit data on more than one level use an indicator called the Qualifier ('Q') bit. 


When only one level of data is being transmitted on a logical channel, the Qualifier 
bit 11S always set to ‘'Q=0"'. When two levels of data are being transmitted, 
transmitting DTEs should set the ‘'Q' bit in all data packets of complete packet 
sequences to the same value, either "0" or '‘"I*, Complete packet sequences, 
transmitted with the '@' bit set to the same value in all packets, are delivered by the 
network as complete packet sequences with the 'Q@’ bit in all packets set to the value 
assigned by the transmitting DTE. 


Other sequences of ‘'Q’ bit settings received cause DTEs to reset the permanent virtual 
circuit or clear the virtual call with the Diagnostic Code #175, “Invalid 'Q*" Bit 
Received". IBM SNA X.25 DTEs must report the contents of the resetting/clearing cause 
and diagnostic code fields to a higher level. 

Actions taken by networks when the 'Q' bit is not set to the same value in all data 
packets of a complete packet sequence by the transmitting DTE is under consideration 
by the CCITT. 


Packets are numbered consecutively (see "Numbering of Data Packets" on page II-38). 
regardless of their data level. 


4.3.6.1 SNA~to-SNA Connections 


The 'Q' bit is used by IBM SNA X.25 DTEs on SNA-to-SNA connections to identify data 
packets associated with the QLLC Logical Link Control procedure described in "Logical 
Link Control CLLC) on SNA~-to-SNA Connections™ on page II-83. 


4.3.6.2 SNA-to-non_SNA Connections 


CCITT Recommendation X.29 provides one example of the procedures to be used when the 
"2" bit is set to '1'. IBM SNA X.25 DTEs that support CCITT Recommendation X.29 and 
other packet assembly/disassembly CPAD) control procedures implement the 'Q' bit 
procedure, accordingly. 


4.3.7 Interrupt Procedure 


6.3.7.1 SNA ~tO-SNA Connections 


The interrupt procedure is not allowed on SNA-to-SNA connections. 
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4.3.7.2 SNA-to-non_SNA Connection 


Interrupt procedures allow DTEs to transmit data to remote DTEs, without following the 
flow control procedures applying to data packets (see "Procedures for Flow Control™). 
The interrupt procedure applies only during the FLOW CONTROL READY state (dl) within 
the DATA TRANSFER state (p4). 


Interrupt procedures have no effect on the transfer and flow control procedures 
applying to data packets on virtual calls or permanent virtual circuits. 


To transmit an interrupt, DTEs transfer a DTE INTERRUPT packet across the DTE/DCE 
interface. DTEs do not transmit a second DTE INTERRUPT packet before a DCE INTERRUPT 
CONFIRMATION packet (see Note 2 to Table C-4) has been received. DCEs, after the 
interrupt procedure is completed at the remote end, confirm receipt of interrupts by 
transferring DCE INTERRUPT CONFIRMATION'~ packets. Receipt of DCE INTERRUPT 
CONFIRMATION packets indicate that interrupts have been confirmed by remote DTEs by 
means of DTE INTERRUPT CONFIRMATION packets. 


DCEs indicate interrupts from remote DTEs by transferring DCE INTERRUPT packets 
containing the same data field as in the DTE INTERRUPT packet transmitted across the 
DTE/DCE interface by the remote DTE. DCE INTERRUPT packets are delivered at or before 
the point in the stream of data packets at which DTE INTERRUPT packets were generated. 
DTEs confirm receipt of DCE INTERRUPT packets by transferring DTE INTERRUPT 
CONFIRMATION packets across the DTE/DCE interface. 


4.4 PROCEDURES FOR FLOW CONTROL 


"Procedures for Flow Control” on page II-37 only applies to the DATA TRANSFER state 
Cp4) and specifies the procedures for controlling the flow of data and reset packets 
on logical channels used for virtual calls or permanent virtual circuits. 


4.46.1 Flow Control 


At the DTE/DCE interface of logical channels used for virtual calls or permanent 
virtual circuits, the transmission of data packets is controlled separately for each 
direction of transmission and 1s based on authorizations from the receiving station. 


On virtual calls or permanent virtual circuits, flow control also allows receiving 
DTEs to limit the rate at which remote DTEs transmit data packets. This 1s achieved by 
the receiving station controlling the rate at which it accepts packets scross the 
DTE/DCE interface, noting that there is a network-dependent limit on the number of 
data packets that can be in the network on a virtual call or permanent virtual circuit. 


6.4.1.1 Numbering of Data Packets 


Data packets. transmitted across the DTE/DCE interface for each direction of 
transmission ona virtual call or permanent virtual circuit are sequentially numbered. 


The sequence numbering scheme of the packets is performed modulo '‘'8'. The packet 
sequence numbers cycle through the entire range '"0* to ‘'7', inclusively. Some 
Administrations provide the Extended Packet Sequence Numbering facility (see 
WExtended Packet Sequence Numbering” on page II-69) which, if selected, provides a 
sequence numbering scheme for packets being performed modulo '128'. In this case, 
packet sequence numbers cycle through the entire range '0' to '127', inclusively. The 
packet sequence numbering scheme, modulo '8' or °128', is the same for both directions 
of transmission and applies to all logical channels at the DTE/DCE interface. 


Note: IBM SNA X.25 DTEs must implement Modulo '8' packet sequence numbering. 
Implementation of modulo '128' packet sequence numbering is optional. 


ees data packets contain this sequence number called the packet send sequence number, 
Ss. 7 
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The first data parvat transmitted across the DTE/DCE interface for a given direction 
of data transmissio~. wren the logical channel has just entered the FLOW CONTROL READY 
state (dl), has 'Ps=C’. 


4.4.1.2 Window Description 


At the DTE/DCE interface of each logical channel used for virtual calls or permanent 
virtual circuits, and for each direction of data transmisston, a window is defined as 
the ordered set of ‘'W' consecutive packet send sequence numbers of data packets 
authorized to cross the interface. 


The lowest sequence number in the window is referred to as the lower window edge. When 
a virtual call or permanent virtual circuit at the DTE/DCE interface has just entered 
the FLOW CONTROL READY state (dl), the window related to each direction of data 
transmission has a lower window edge equal to '0Q'. 


The Ps of the first data packet not authorized to cross the DTE/DCE interface is the 
value of the lower window edge plus 'W' modulo '8' Cor '128' when extended). 


The standard window size, ‘'W', 1s two (2) for each direction of data transmission at 
the DTE/DCE interface. Other window sizes may be offered by some network 
Administrations. An optional window size may be selected for a period of time as the 
default window size common to all virtual calls at the DTE/DCE interface (see 
"Non-Standard Default Window Sizes” on page II-69). A value other than the standard 
default may be selected for a period of time for each permanent virtual circuit (see 
"Non-Standard Default Window Sizes" on page II-69. Negotiation of window sizes, ona 
per call basis, may be made with the Flow Control Parameter Nesotiation facility (see 
"Flow Control Parameter Negotiation” on page II-73). 


IBM SNA X.25 DTEs must implement 'W=2' and also allow values other than 'W=2', namely, 
TW’ < 'modulus’ to be set as determined at subscription time. When the access link to 
the network exhibits long delay characteristics and the packets used are short, IBM 
SNA X.25 DTEs may implement the optional Flow Control Parameter Negotiation facility 
as not all networks permit selection of default values other than '"W=2". 


4.4.1.3 Flow Control Principles 


When the Ps of the next packet to be transmitted is within the window, transmitting 
stations are authorized to transmit that data packet to the receiving station. When 
the Ps of the next data packet to be transmitted is outside of the window, transmitting 
stations do not transmit data packets. (Text deleted). 


When the Ps of the data packet received is the next in-sequence (text deleted) 
receiving stations may accept the data packet. A received data packet containing a Ps 
that ts out of sequence (i.e., there 1s a duplicate or a gap in the Ps numbering), 
outside the window or not equal to '0' for the first data packet received after 
entering the FLOW CONTROL READY state (di) is considered by DCEs to be a local 
procedure error. In this event DCEs reset the virtual call or permanent virtual 
circuit (see "Procedure for Reset” on page II-42). DTEs consider the receipt of a data 
packet containing a Ps that is out of sequence (i.e., there 1s a duplicate or a gap in 
the Ps numbering), (text deleted) or not equal to '0' for the first data packet 
received after entering the FLOW CONTROL READY state (dl) to be a hard DCE failure and 
either clear the virtual call or reset the permanent virtual circuit, or restart the 
DTE/DCE interface. The contents of clearing/resetting Cause and Diagnostic Code 
fields must be reported to a higher level. 


Some networks do not tnvoke the error procedure on receipt of data packets containing 
a Ps that 15 out of sequence but 1s within the window. These networks may pass on such 
packets to remote DTEs to make it possible for local DTEs to retransmit packets on 
virtual calls or permanent virtual circuits (within the national network). 


Because packets should never get out of order on SNA-to-SNA connections (packet level 
retransmission does not occur), an out-of—-sequence Ps should be treated as an error. 
DTEs clear the virtual call or reset the permanent virtual circuit Con SNA-to-SNA 
connections with the diagnostic code #171', "Invalid PS", see Appendix F) and must 
report the error to a higher level. 
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A number mudulo *8* Cor '128* when extended) referred to as a packet receive sequence 
number (Pr), conveys information from the receiver across the DTE/DCE interface for 
the transmission of data packets. Pr's become the lower window edge when transmitted 
across the DTE/DCE interface. In this way, additional data Reckes= are authorized to 
cross the DTE/DCE interface by the receiving station. 


Pr's are conveyed in data, receive ready (RR) and receive not ends CRNR) packets. 


The value of a Pr received must be within the range from the last Pr received up to and 
including the Ps of the next data packet to be transmitted. Otherwise, DCEs consider 
the receipt of this Pr to be a procedure error and reset the virtual call or permanent 
virtual circuit. DTEs consider the receipt of a Pr value that is not within the range 
from the last Pr received up to and including the Ps of the next data packet to be 
transmitted as a DCE hard failure and either reset the permanent virtudal circuit or 
clear the virtual call, or restart the DTE/DCE interface. Such failures must be 
reported to a higher level. On SNA-to-SNA connections the Diagnostic Code #172', 
"Invalid Pr™, (see Appendix F) 1s used. | 


Pr‘s are less than or equal to the sequence number of the next expected data packet and 
imply. that the transmitting station has accepted at least all data packets numbered up 
to and including 'Pr-1'. 


4.4:1.94 Delivery Confirmation 


When ‘'D=0" in a data packet having '‘'Ps=p', significance of the returned Pr 
corresponding to that data packet Ci.e., "Pr2ptl") is a local updating of the window 
across the packet level DTE/DCE interface so that the achievable throughput 1s not 
constrained by the DTE-to-DTE round trip delay across the network(s). 


1. SNA-to-SNA Connections 


"'D=1" js not allowed on SNA-to-SNA connections. If a packet with 'D=1' jis 
received on an SNA-to-SNA connection, IBM SNA X.25 DTEs clear the virtual call or 
reset the permanent virtual circuit with the Diagnostic Code #173, "Invalid ‘'D' 
Bit Received in Data Packet” (see Appendix F?). 


If an INCOMING CALL or CALL CONNECTED packet is received with bit 7='"1', IBM SNA 
X.25 DTEs clear the call with the Diagnostic Code #233, "Invalid "D' Bit Request" 
(see Appendix F). In all cases, the error condition and Cause and Diagnostic 
codes must be reported to a higher level. 


2. SNA-to-non_SNA Connections 


When 'D=1' in a data packet having 'Ps=p'*, the significance of the returned Pr 
corresponding to that data packet (i.e., 'Pr2ptl') 1s an indication that a Pr has 
been received from the remote DTE for all data bits in the data packet which 
originally had 'D=1'. 


Note: 


1. DTEs, upon receipt of a data packet with ‘'D=1', transmit the corresponding Pr as 
soon as receipt of the packet at its destination within the SNA network has been 
acknowledged by the appropriate response. Data, RR or RNR packet may be used to 
convey the Pr (Csee note to "DTE and DCE Receive Not Ready (RNR) Packets." 
Likewise, DCEs are required to send Pr to the DTE as soon as possible after the Pr 
is received from the remote DTE. DTEs should not defer updating the window for 
previous packets with 'D=0' while waiting for acknowledgement of a packet with 
*Dp=)'°., : 

2. In the case where a Pr for a data packet with 'D=1" is outstanding, local updating 
of the window is deferred for subsequent data packets with 'D=0'. Some networks 
may also defer updating the window for previous data packets (within the window) 
with "D=0' until the corresponding Pr for the packet with the outstanding "D=1' is 
transmitted to the DTE. 


3. Pr values corresponding to the data contained in data packets with the 'D=1' need 
not be the same at the DTE/DCE interfaces at each end of a virtual call or 
permanent virtual circuit. 
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4. If the virtual call has not been established indicating support of the '"D' bit 
procedure, IBM SNA X.25 DTEs do not send data packets with 'D=l1'. If they receive 
a packet with 'D=1" from a non-SNA DTE they accept the packet by returning the 
corresponding Pr as soon as possible, without waiting for any SNA acknowledgement. 


6.4.1.5 DTE and DCE Receive Ready (RR) Packets 


RR packets are used by transmitting stations to indicate that they are ready to. 
receive the 'W' data packets within the window starting with Pr, where Pr is indicated 
in the RR packet. 


4.4.1.6 DTE and DCE Receive Not Ready (RNR) Packets 


RNR packets are used by transmitting stations to indicate a temporary inability to 
accept additional data packets for a given virtual call or permanent virtual circuit. 
Stations receiving an RNR packet stop transmitting data packets on the indicated 
logical channel, but the window is updated by the Pr value of the RNR packet. The 
receive not ready situation indicated by the transmission of an RNR packet is cleared 
by the transmission in the same direction of an RR packet or by initiation of a reset 
procedure. 


The transmission of an RR packet after an RNR packet at the packet level is not to be 
taken as a demand for retransmission of packets which have already been transmitted. 


Note: RNR packets may be used to convey the Pr value corresponding to the data packet 
which had 'D=1' across the DTE/DCE interface when additional data packets cannot be 
accepted on SNA-to-non_SNA connections. 


6.4.2 Throughput Characteristics and Classes 


The attainable throughput on virtual calls and permanent virtual circuits carried at 
the DTE/DCE interface may vary due to the statistical sharing of transmission and 
switch resources and is constrained by: 


® the access line characteristics, local window size and traffic characteristics of 
other logical channels at the local DTE/DCE interface; 


e the access line characteristics, local window size and traffic characteristics of 
other logical channels at the remote DTE/DCE interface; and, 


e the throughput achievable on the virtual call or permanent virtual circuit through 
the network(s) independent of interface characteristics including number of 
active logical channels. This throughput may be dependent on network service 
characteristics such as window rotation mechanisms and/or optional user 
facilities requested on national/international calls. 


The attainable throughput will also be affected by: 
°. the receiving DTE flow controlling the DCE; 


e the transmitting DTE not sending data packets. which have the maximum data field 
length; 


e the local DTE/DCE window and/or packet sizes; and, 

® [the use of the 'D' bit.] 

A throughput class for one direction of transmission is an inherent characteristic of 
the virtual call or permanent virtual circuit related to the amount of resources 
allocated to this virtual call or permanent virtual circuit. This characteristic is 


meaningful when 'D=0' in data packets. It is a measure of the throughput that is not 
normally exceeded on the virtual call or permanent virtual circuit. However, due to 
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the statistical sharing of transmission and switching resources, it is not guaranteed 
that the throughput class can be reached 100% of the time. 


Depending on the network and the applicable conditions at the considered moment, the 
effective throughput may exceed the throughput class. 


Text deleted. 
The throughput class may only be reached if the following conditions are met: 


1. the access data links at both ends of a virtual call or permanent virtual circuit 
are engineered for the throughput class; 


2. the receiving DTE is not flow controlling the DCE such that the throughput class. 
is not reachable; 


3. the transmitting DTE is sending data packets which have the maximum data field 
length; and, . 


4. all data packets transmitted on the virtual call or permanent virtual circuit have 
'p=9! 


Throughput class is expressed in bits per second. At a DTE/DCE interface, the maximum 
user data field length is specified for a virtual call or permanent virtual circuit, 
and thus the throughput class can be interpreted by DTEs as the number of full data 
packets/serond that the DTE does not have a need to exceed. 


In the absence of the Default Throughput Class Assignment facility (see "Default 
Throughput Classes Assignment" on page II-69), the default throughput classes for both 
directions of transmission correspond to the user class of service of the DTE (see 
"Coding of Throughput Class Negotiation Facility” on page II-81) but do not exceed the 
maximum throughput class supported by the network. Negotiation of throughput classes 
on a per call basis may be made with the Throughput Class Negotiation facility (see 
"Throughput Class Negotiation" on page II-74). 


Note: The summation of throughput classes of all virtual calls and permanent virtual 
circuits (text deleted) supported at a DTE/DCE interface may be greater than the data 
transmission rate of the access line. 


4.4.3 Procedure for Reset 


The reset procedure is used to reinitialize virtual cailis or permanent virtual 
circuits and in so doing removes in each direction of transmission all data land 
interrupt] packets which may be in the network (see "Effects of Clear, Reset and 
Restart Procedures on the Transfer of Packets” on page II-43). When a virtual call or 
permanent virtual circuit at the DTE/DCE interface has just been reset, the window 
related to each direction of data transmission has a lower window edge equal to '0', 
and the numbering of subsequent data packets to cross the DTE/DCE interface for each 
direction of data transmission starts from ‘0°. 


The reset procedure can only apply in the DATA TRANSFER state (p4) of the DTE/DCE 
interface. In any other state of the DTE/DCE interface, the reset procedure 1s 
abandoned. For example, when a clearing or restarting procedure is initiated, RESET 
REQUEST and RESET INcCICATION packets can be left unconfirmed. 


For flow control, there are three states di, d2, and d3 within the DATA TRANSFER state 
(p4). They are FLOW CONTROL READY (Cdl), DTE RESET REQUEST (d2), and DCE RESET 
INDICATION (€d3) as shown in the state diagram in Figure B-3 of Appendix 8B. When 
entering state p4, the logical channel is placed itn state dl. Table C-4 specifies 
actions taken by DCEs upon receipt of packets from DTEs. Table G-4, in Appendix G, 
specifies actions taken by DTEs upon receipt of packets from DCEs. 


4.4.3.1 Reset Request Packet 


DTEs indicate requests for resetting of permanent virtual circuits by transmitting a 
RESET REQUEST packet, specifying the logical channel, across the DTE/DCE interface. 
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This places the specified logical channel in the DTE RESET REQUEST state (d2). DTEs 
discard data, [Linterrupt,] RR, and RNR packets received on logical channels in the DTE 
RESET REQUEST state. Packets of incomplete packet sequences received in this state, 
are also discarded. 


A diagnostic code as defined in Appendix F must be included. Error conditions that 
cause a reset must be reported, with associated diagnostic codes, to a higher level. 
If the time spent in state (d2) exceeds 200 seconds, the RESET REQUEST packet can be 
restransmitted after the 200 second timer is reinitialized. If the total time spent 
in state (d2) exceeds ‘n't times 200 seconds, where 'n21"', notification of the RESET 
REQUEST failure must be reported to a higher level using the diagnostic code #51; the 
logical channel is placed in an inoperative state. 


4.4.3.2 Reset Indication Packet 


DCEs indicate a reset by transmitting a RESET INDICATION packet, specifying the 
logical channel and the reason for the resetting, across the DTE/DCE interface. This 
places the specified logical channel in the DCE RESET INDICATION state (d3). DCEs 
ignore data, Cinterrupt,] DTE RNR and DTE RR packets received on logical channels in 
the DCE RESET INDICATION state. DTEs discard untransmitted packets of send packet 
sequences and must notify a higher layer of the inoperative condition, reporting the 
contents of the resetting cause and diagnostic fields. 


IBM SNA X.25 DTEs that receive RESET INDICATION packets on logical channels assigned 
for virtual calls clear the virtual call with the diagnostic code #234, "Reset 
Indication on Virtual Call”. 


RESET INDICATION packets are used as ae normal sequence for packet level 
initialization, e.g.: 


® A RESET INDICATION packet with Cause "Out-of-Order (#1)" is returned by the 
X.25-based network to indicate that the remote DTE/DCE interface has not, as yet, 
been initialized. 


® A RESET INDICATION packet with Cause "DTE Originated '"0'" and Diagnostic Code "PU 
Not Available #226" is returned by an SNA NIA to indicate that the SNA SDLC link 
nas not, as yet, been initialized. 


C RESET INDICATION packets are propagated by X.25-based networks for each permanent 
virtual circuit as a result of a restarting procedure at the remote DTE/DCE 
interface. Such RESET_INDICATION packets may contain either: 


— the network generated Cause '9' (Remote DTE Operational) with an appropriate 
Diagnostic code; or, 


= the DTE Originated Cause '0' with the Diagnostic code passed through from the 
associated RESTART_REQUEST packet. 


4.4.3.3 Reset Collision 


Reset collision occurs when a DTE and a DCE simultaneously transmit a RESET REQUEST 
packet and a RESET INDICATION packet specifying the same logical channel. In this 
event DCEs consider the reset to be complete. DCEs do not expect a DTE RESET 
CONFIRMATION packet and do not transfer a DCE RESET CONFIRMATION packet. DTEs do not 
expect a DCE RESET CONFIRMATION packet and do not transfer a DTE RESET CONFIRMATION 
packet when a reset collision occurs. This places the specified logical channel in 
the FLOW CONTROL READY state (dl). 


4.4.3.4 Reset Confirmation Packets 


When a logical channel is in the DTE RESET REQUEST state (d2), DCEs confirm the reset 
by transmitting a DCE RESET CONFIRMATION packet across the DTE/DCE interface. This 
places the specified logical channel in the FLOW CONTROL READY state (dl). 
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DCE RESET CONFIRMATION packets can only be interpreted universally as having local 
significance, however, within some Administration's networks, reset confirmation may 
have end-to-end significance. In any event the time spent in the DTE RESET REQUEST 
state (d2) will not exceed time-limit T22 (see Appendix D). 


When logical channels are in the DCE RESET INDICATION state (d3), DTEs confirm the 
reset by transmitting a DTE RESET CONFIRMATION packet before time T12 elapses. This 
places the specified logical channel in the FLOW CONTROL READY state (dl). Actions 
taken by DCEs when DTEs do not confirm the reset within time-out T1l2 are given in 
Appendix D. 


4.5 EFFECTS OF CLEAR, RESET AND RESTART PROCEDURES ON THE TRANSFER OF PACKETS 


All data Land interrupt] packets generated by a DTE (or the network) before initiation 
of a clear, reset or restart procedure by a station at the local interface are either 
delivered to the remote DTE before the DCE transmits the corresponding indication on 
the remote interface, or discarded by the network. 


Data for interrupt] packets generated by a DTE (Cor the network) after the completion 
of a reset (Cor for permanent virtual circuits also a restart) procedure at the local 
interface are not delivered to the remote DTE before completion of the corresponding 
reset procedure at the remote interface. 


When a DTE initiates a clear, reset or restart procedure on its local interface, all 
data and Linterrupt] packets which were generated by the remote DTE (or the network) 
before the corresponding indication is transmitted to the remote DTE are either 
delivered to the initiating DTE before DCE confirmation of the initial clear, reset or 
restart request, or discarded by the network. 


Note: The maximum number of packets that may be discarded is a function of network 
end-to-end delay and throughput characteristics and, in general, has no relation to 
the local Window size. (Text deleted.) 


(Text deleted. } 


4.5.1 SNA-to-non SNA Connections 


[For virtual calls on which all data packets are transferred with the 'D=1', the 
maximum number of packets that may be discarded in one direction of transmission is 
never larger than the window size for the direction of transmission]. 


4.6 EFFECTS OF PHYSICAL AND LINK LEVEL FAILURES 

When a failure at the pnysical and/or link level is detected, DCEs transmit to the 
remote end: 

1. a reset with the cause "Out of Order” for each permanent virtual circuit; and, 

2. aclear with the cause "Out of Order™ for each existing virtual call. 

DCEs clear incoming virtual calls received until the failure is recovered. 

When physical and link level failures are recovered, a restart procedure is executed 
(see "Effects of the Physical Level and the Link Level on the Packet Level” on page 
II-28) and a reset with the cause "Remote DTE Operational” is transmitted to the 


remote end of.each permanent virtual circuit. DTEs must report "Out of Order™ cause 
and diagnostic codes to a higher level. 
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5.0 PROCEDURES FOR DATAGRAM SERVICE 


Datagram services are not used by IBM SNA X.25 DTEs. In the event that a DATAGRAM or 
DATAGRAM SERVICE SIGNAL packet is received, IBM SNA X.25 DTEs clear the virtual call 
or reset the permanent virtual circuit with the Diagnostic Code #170 'Not Supported’. 


(Text deleted). 
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6.0 PACKET FORMATS 


6.1 GENERAL 


The possible extension of X.25 packet formats by the addition of new fields is being 
considered by the CCITT. 


Note: Any such field: 


1. would only be provided as additions following all previously defined fields, and 
not as insertions between any previously defined fields; 


2. would be transmitted to a DTE only when either the DCE has been informed that the 
DTE is able to interpret this field and act upon it, or when the DTE can ignore the 
field without adversely affecting the operation of the DCE; and, 


3. would not contain any information pertaining to a user facility to which the DTE 
has not subscribed. 


Bits of an octet are numbered 8 to 1 where bit 1 is the low order bit and is 
transmitted first. Octets of a packet are consecutively numbered starting from '1' 
and are transmitted in this’ order. Octets of sub-fields within a packet are 
consecutively numbered starting from '0*. 
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For example a packet: 


Bits 
3 7 6 5 4 3 2 1. 
Octet 
1 General format identifier (GFI) Logical channel group number 
0 «0 0 1 0 0 1 0 
2 Logical channel number | 
0 0 0 0 0 0 0 1 
3 Packet type identifier 
0 0 0 0 1 0 1 1 
4 Calling DTE address length Called DTE address length 
0 1 0 0 0 1 0 1 
5 0 0 0 Called 
DTE 
6 Address 
7 Calling 
DTE 
8 Address 
9 
Facility Length 
10 0 0 0 0 0 0 
Call Protocol Identifier 
User l 1 0 0 0 0 1 1 
Data [rom orm tr rr rrr wm wr rm wr nr sens sees ee eee 
Field Up to 15 Octets 


would appear on the transmission link as a string of: 


e binary bits in the order: 
"xxx. ..xxxX1100001100000000..... 0000000100010010'>>; 

e¢ hexadecimal digits in the order: 
"XrXp eee 9KeMXrCr5,0,0..... »0,1,1,2">>; or, 

e octets containing hexadecimal values in the order: 
"xKX,..-2xXxX,C3,00,..... 201,12'>>, 

where the first bit(€s) transmitted are immediately to the left of ‘>>. 


Figure 1. Octet Numbering: Call Set-up/Clearing Packet 


6.1.1 General Format Identifier 


The General Format Identifier (GFI) field is a four bit binary coded field that 
indicates the general format of the rest of the packet header. The General Format 
Identifier field occupies bit positions 8, 7, 6 and 5 of octet 1l, and bit 5 is the low 
order bit (see Table II-7). 
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Call set-up 


Table II-7 — General Format Identifier 


General format identifier 


Sequence Numbering Scheme 
modulo 8: 


0X10 


Sequence Numbering Scheme 
modulo 128 


Clearing, datagram, flow | Sequence Numbering Scheme oeee 


packets 


QO. 
—~ 
0o 


control, interrupt, reset, modulo 8 
restart and diagnostic 
packets Sequence Numbering Scheme 
modulo 128 


Sequence Numbering Scheme XXO01 
modulo 8 
Data packets 
| Sequence Numbering Scheme Xx X10 
modulo 128 
Sequence numbering Scheme 1001 
Datagram service signal modulo 8 
packets 


Sequence Numbering Scheme 1010 
modulo 128 


| General Format Identifier extension pe X11 | 


* Undefined | 


Note: A bit which is indicated as "X" may be set to either "0" or '1" as 
indicated in the text. 


a a the General Format Identifier is the Qualifier "Q' bit in data packets. (Text 
deleted). | 


Bit 7 of the General Format Identifier is used for the delivery confirmation procedure 
in data and call set-up packets and is set to '0' in all other packets. It must be '0° 
in all packets on SNA-to-SNA connections. 


Bits 6 and 5 are encoded for four possible indications... Two of the codes are used to 
distinguish packets using modulo '8* packet sequence numbering from packets using 
modulo ‘'128' packet sequence numbering. The third code is used to indicate an 
extension to an expanded format for a family of General Format Identifier codes which 
are being considered by the CCITT. The fourth code is unassigned. 


Note: 


1. In the absence of the extended packet sequence numbering facility (see "Extended 
Packet Sequence Numbering™ on page II-69), the sequence numbering scheme is 
performed modulo 8. | 


2. It is envisaged that other . general format identifier codes could identify 
alternative packet formats. 


6.1.2 Logical Channel Group Number 


The Logical Channel Group Number appears in every packet except restart packets and 
diagnostic packets in bit positions 4, 3, 2 and 1 of octet 1. For each logical. 
channel, thts number has local significance at the DTE/DCE interface. 
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This field is binary coded and bit 1 is the low order bit of the Logical Channel Group 
Number. In restart and diagnostic packets, this field is coded x'0'. 


6.1.3 Logical Channel Number 


The Logical Channel Number appears in every packet except restart packets and 
diagnostic packets in all bit positions of octet 2. For each logical channel, this 
number has local significance at the DTE/DCE interface. 


This field is binary coded and bit 1 is the low order bit of the Logical Channel 
Number. In restart and diagnostic packets, this field is coded x'00'. 


6.1.4 Packet Type Identifier 


Each packet is identified in octet 3 as shown in Table II-8. 


Table II-8 — Packet Type Identifier 


PACKET TYPE 


From DCE to DTE From DTE to DCE 


CALL SET-UP AND CLEARING 
INCOMING CALL — INC CALL REQUEST — CRQ 
CALL CONNECTED — CCN CALL ACCEPTED —CAC 
CLEAR INDICATION — CLI CLEAR REQUEST — CLR 
DCE CLEAR DTE CLEAR 
CONFIRMATION — NCC CONFIRMATION — TCC 


DATA AND CINTERRUPT] 
DCE DATA — NDT DTE DATA — TDT 
DCE CINTERRUPT] — NIN DTE CLINTERRUPTJ — TIN 
DCE CINTERRUPT] DTE CINTERRUPT] 
CONFIRMATION — NIC CONFIRMATION — TIC 


DATAGRAM 
DCE DATAGRAM DTE DATAGRAM 
DATAGRAM SERVICE SIGNAL 


FLOW CONTROL AND RESET 

DCE RR (CMOD 8) — NRR DTE RR CMOD 8) — TRR 
DCE RR (MOD 128) " DTE RR (MOD 128) ie 
DCE RNR CMOD 8) — NNR DTE RNR CMOD 8) — TNR 
DCE RNR (MOD 128) ” DTE RNR (MOD 128)% " 

DTE REJ CMOD 8) 

DTE REJ (MOD 128)* 
RESET INDICATION — RSI RESET REQUEST — RSR 
DCE RESET DTE RESET |. 
CONFIRMATION — NRC | CONFIRMATION — TRC 


RESTART 
RESTART INDICATION — IRI RESTART REQUEST — IRR 
DCE RESTART DTE RESTART 
CONFIRMATION — NSC CONFIRMATION — TSC 


DIAGNOSTIC 


H~ MODODOGOO 
~~ KR RR OO0OO 
He DBDOOrFFHOO 
—- MmMOooo0o 
ee 


DIAGNOSTIC — DGN 


* = Not necessarily available on every network. 


Note: A bit which is indicated as "X" may be set to either '0" or 'l’' as 
indicated in the text. 
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6.2 CALL SET-UP AND CLEARING PACKETS 


6.2.1 Call Request and Incoming Call Packets 


Figure 2 illustrates the format of CALL REQUEST and INCOMING CALL packets. 


Bits 
8 7 6 5 4 3 2 1 


Octet 
1 


General Format Identifier (GFI) 


Logical Channel Group Number 


2 Logical Channel Number 
3 Packet Type Identifier 
0 0 0 0 1 1 1 
: DTE Address (see Note 2) 
: Facility Length 
, Facilities | 
n Call User Data (see Notes 3 and 4) 


Figure 2. CALL REQUEST and INCOMING CALL: Packet Format 
Notes to Figure 2: 
1. GFI - Coded 0X01 Cmodulo 8) or 0X10 Cmodulo 128). 
Where: "X = 0" on SNA-to-SNA Connections. 
"X = 0 or 1° on SNA-to-non SNA Connections. 


2. The figure 1s drawn assuming a single address, consisting of an odd number of 
octets, 15 present. 


3. The first octet of the Call User Data field is required and bits 8» 7 and 2 nave 
particular significance (see Protocol Identifier (PI)). 


4. Maximum length of the call user data field is 16 Octets. 
5. The Calling DTE Address in CALL REQUEST packets is optional. 
6. Facilities in CALL REQUEST and INCOMING CALL packets are optional. 


6.2.1.1 General Format Identifier 


On SNA-to-non SNA connections, bit 7 of octet 1 is set to '0" unless the '"D!' bit 
mechanism defined in “Delivery Confirmation (DD) Bit™ on page II-33 is used. CALL 
REQUEST and INCOMING CALL packets must have bit 7 of octet 1 set to '0"' on SNA-to-SNA 
connections. 


6.2.1.2 Address Lengths Field 


Octet & consists of field length indicators for the called and calling DTE addresses. 
Bits 4, 3, 2 and 1 indicate the length of the called DTE address in semi-octets. Bits 
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8» 7, 6 and 5 indicate the length of the calling DTE address in semi-octets. Each 
address length indicator is binary coded and bit 1 or bit 5 is the low order bit of the 
tndicator. 


6.2.1.3 Address Field 


Octet 5 and the following octets consist of the called DTE address, when present, then 
the calling DTE address, when present. 


Each digit of an address is coded ina semi~octet in binary coded decimal with bit 5 or 
bit 1 being the low-order bit of the digit. 


Starting from the high order digit, the address is coded in octet 5 and consecutive 
octets with two digits per octet. In each octet, the higher order digit is coded in 
bits 8, 7, 6 and 5. 


The Address field is rounded up to an integral number of octets by inserting zeros in 
bits 4, 3, 2 and 1 of the last octet of the field when necesSary. 


(Text deleted. ) 


6.2.1.4 Facility Length Field 


Bits 6, 5, 4, 3, 2 and 1 of the octet following the Address field indicate the length 
of the Facility field in octets. The facility length indicator is binary coded and bit 
1 is the low order bit of the indicator. 


Bits 8 and 7 of this octet are unassigned and set to '0's. 


6.2.1.5 Facility Field 


The Facility field is present only when the DTE is using an optional user facility 
requiring some indication in CALL REQUEST and INCOMING CALL packets. 


The coding of the Facility field is defined in "PROCEDURES AND FORMATS FOR OPTIONAL 
USER FACILITIES" on page II-69. 


The Facility field contains an integral number of octets. The actual maximum length 
of this field denends on the facilities that are offered by the network. However, this 
maximum does not exceed 63 octets. 


6.2.1.6 Call User Data Field 


Octets following the Facility field are the Call User Data field, which must be an 
integral number of octets and has a maximum length of 16 octets. 


Protocol Identifier (PI) 


The first octet of the Call User Data field is the Protocol Identifier which is 
mandatory in SNA environments. 


(Text deleted). 


The use and format of the Call User Data field is determined by the setting of bits 8 
and 7 of the first octet of this field (Protocol Identifier). If bits 8 and 7 of the 
first octet of the Call User Data field are: 


® *00' a portion of the Call User Data field is used for protocol identification in 


accordance with CCITT Recommendation X.29. This setting is not considered for IBM 
SNA X.25 DTEs in this version of the specification. 
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® "01" a portion of the Call User Data field may be used for protocol identification 
tn accordance with the specifications of network Administrations. This setting is 
not considered for IBM SNA X.25 DTEs in this version of the specification. 

e "10" a portion of the Call User Data field may be used for protocol identification 
in accordance with specifications of international user bodies. This setting 15s 
not considered for IBM SNA X.25 DTEs in this version of the specification. 

° "11" the Call User Data belongs to a higher level, 

Users are cautioned that if bits 8 and 7 of the first octet of the Call User Data field 

are set to any value other than '11', a protocol may be identified that is implemented 

within some public data networks. 


Receipt of an incorrect setting of bits 8 or 7 Cother than '11"'), by IBM SNA X.25 DTEs 
results in call clearing with the diagnostic code #234, "Invalid Protocol Identifier”. 


Bit 2 of the Protocol Identifier also has particular significance in SNA environments: 


e "0" for SNA-to-non_SNA connections; or, 
e "1" for SNA-to-SNA connections. 


All Protocol Identifier code points are reserved except: 
e x'CO® and x'C1* for SNA-to-non SNA connections; and, 


° x'C2"', x'C3" and x'C6" for SNA-to-SNA connections (see "Logical Link Control (LLC) 
on SNA-to-SNA Connections” on page II-83). | 


Note: When a virtual call is being established between two packet mode DTEs, the 
network does not act on any part of the Call User Data field. (text deleted.) 


6.2.2 Call Accepted and Call Connected Packets 


Figure 3 illustrates the format of CALL ACCEPTED and CALL CONNECTED packets. 


Bits 
8 7 6 5 4 3 2 1] 
Octet : 
1 General format identifier (CGFI) Logical channel group number 
2 Logical channel number 
3 Packet type identifier 
0 1 
4 
n Facilities* 


¥—These fields are not mandatory in CALL ACCEPTED packets 
(see §-6.2.2). 


Figure 3. CALL ACCEPTED and CALL CONNECTED: Packet Format 
Notes to Figure 3: 
1. GFI - Coded 0X01 (modulo 8) or 0X10 (modulo 128). 
Where X = '0" on SNA-to-SNA connections; and, 


"0" or '1" on SNA-to-non SNA connections. 
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2. The figure is drawn assuming that a single address is present consisting of an odd 
number of digits. 


6.2.2.1 General Format Identifier 
On SNA-to-non SNA connections, bit 7 of octet 1 is equal to '0" unless the '"D' bit 
mechanism defined in "Delivery Confirmation (D) Bit™ on page II-33 is used. 


CALL ACCEPTED packets and CALL CONNECTED packets must have bit 7 of octet 1 set to '0' 
on SNA-to-SNA connections. 


6.2.2.2 Address Lengths Field 


Octet 4 contains field length indicators for called and calling DTE addresses. Bits 
4, 3, 2 and 1 indicate the length of the called DTE address in semi-octets. Bits 8, 7, 
6 and 5 indicate the length of the calling DTE address in semi-octets. Each address 
length indicator is binary coded and bit 1 or 5 is the low order bit of the indicator. 


The use of the Address Lengths field in CALL ACCEPTED packets is only mandatory when 
the Address field or the Facility Length field is present. 


6.2.2.3 Address Field 
Octet 5 and the following octets consist of the called DTE address when present, then 
the calling DTE address when present. 


Each digit of an address is coded in a semi~octet in binary coded decimal with bit 5 or 
1 being the low-order bit of the digit. 


Starting from the high order digit, the address is coded in octet 5 and consecutive 
octets with two digits per octet. In each octet, the higher order digit is coded in 
bits 8, 7, 6 and 5. 


The Address field is rounded up to an integral number of octets by inserting zeros in 
bits 4, 3, 2 and 1 of the last octet of the field when necessary. 


(Text deleted. ) 


6.2.2.% Facility Length Field 


Bits 6, 5, 4, 3, 2, and 1 of the octet following the Address field indicate the length 
of the Facility field in octets. The facility length indicator is binary coded and bit 
1 is the low order bit of the indicator. 

Bits 8 and 7 of this octet are unassigned and set to "00". 


The use of the Facility Length field in CALL ACCEPTED packets is only mandatory when 
the Facility field is present. | 


6.2.2.5 Facility Field 


The Facility field is present only when the DTE is using an optional user facility 
requiring some indication in the CALL ACCEPTED and CALL CONNECTED packets. 


The coding of the Facility field is defined in "FROCEDURES AND FORMATS FOR CPTIONAL 
USER FACILITIES" on page II~-69. 
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The Facility field contains an integral number of octets. The actual maximum length 
of this field depends on the facilities which are offered by the network. However, 
this maximum does not exceed 63 octets. 


6.2.3 Clear Request and Clear Indication Packets 


Figure §& illustrates the format of CLEAR REQUEST and CLEAR INDICATION packets. 


Bits 
7 6 5 4 3 2 1 


8 
Octet 
i General format identifier (GFI) Logical channel group. number 


2 Logical channel number 
3 Packet type identifier 
0 1 0 
Clearing cause 
5 Diagnostic code 


(This field is mandatory on SNA-to-SNA Connections 
(see Appendix F)) 


Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 4. CLEAR REQUEST and CLEAR INDICATION: Packet Format 


6.2.3.1 Clearing Cause Field 


Octet 4 is the Clearing Cause field and contains the reason for clearing the call. 
The bits of the Clearing Cause field in CLEAR REQUEST packets are set to '"0* by DTEs. 
(Text deleted). | 


aa of the Clearing Cause field in CLEAR INDICATION packets is given in Table 
I = ° , 
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Table II-9 — Coding of the Clearing Cause Field in 
CLEAR INDICATION packets 
Bits 8 7 6 5 4321 

DTE Oridinated 0000 0000 | 


Number busy 0 0 0001 01 
Out of order 0 0 10041 09 
Remote procedure error 0 10001 17 
Reverse charging acceptance not subscribed* 0 1 13100441 25 
Incompatible destination 0 0 00041 33 
Fast select acceptance not subscribed* 0 0 1001 41 
Invalid facility request 0 0 0011 
Access barred 0 0 1011 
Local procedure error 0 100141 
Network congestion 0 0 6 0101 05 
Not obtainable 0 oO 1101 13 
RPOA out of order 0 1 0101 


*¥ May be received only if the corresponding optional user facility 
is used. 
DEC — decimal 


6.2.3.2 Diagnostic Code 


Octet 5 contains the Diagnostic Code and provides additional information on the reason 
for clearing the call. 


Diagnostic Codes generated by IBM SNA X.25 DTEs for CLEAR REQUEST packets on 
SNA-to-SNA connections are specified in Table F-l. 


In a CLEAR INDICATION packet, if the Clearing Cause field indicates "DTE Originated", 
the Diagnostic Code is passed unchanged from the clearing DTE. If the clearing. DTE has 
not provided a Diagnostic Code in its CLEAR REQUEST packet, the bits of the Diagnostic 
Code in the resulting CLEAR INDICATION packet are '0°*. 


When a CLEAR INDICATION packet results from a RESTART REQUEST packet, the value of the 
Diagnostic Code will be that specified in the RESTART REQUEST packet or '0' when no 
Diagnostic Code has been specified in RESTART REQUEST packets 


When the Clearing Cause field does not indicate "DTE Originated,” the Diagnostic Code 
in a CLEAR INDICATION packet is network generated. Appendix E lists the codings for 
network generated diagnostics. The Diagnostic Code field is set to '0' when no 
specific additional information on the reason for clearing the call 1s supplied. 


Note: The contents of the Diagnostic Code field do not alter the meaning of the Cause 
field. IBM SNA X.25 DTEs must report the contents of the Diagnostic Code and Clearing 
Cause fields to a higher level. DTEs shall not refuse to accept the Cause field 
because the Diagnostic Code field contains an unspecified code combination. 


6.2.4 DTE and DCE Clear Confirmation Packets 


Figure 5 illustrates the format of DTE and DCE CLEAR CONFIRMATION packets. 
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| Bits 
8 7 6 5 G 3 2 1 
Octet 
1 


General format identifier (GFI) Logical channel group number 


2 Logical channel number 


3 Packet type identifier 
1 0 


Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 5. DTE and DCE CLEAR CONFIRMATION: Packet Format 
| 6.3 DATA [LAND INTERRUPT] PACKETS 


6.3.1 DTE and DCE Data Packets 


Figure 6 illustrates the format of DTE and DCE DATA packets. 


| Bits 
| 8 7 6 5 4 3 2 1 
Octet 
1 General format identifier (GFI) Logical channel group number 
Q D 0 1 
2 Logical channel number 
3 
n Call user data 
(Modulo 8) 
: Bits 
8 7 6 5 G 3 2 1 


n User data 


C(Modulo 128) 
"D' = Delivery confirmation bit C= '0" on SNA-to-SNA Connections). 
*M*' = More Data'bit 
"Q' = Qualifier bit 
Figure 6. DTE and DCE DATA: Packet Format 


6.3.1.1 Qualifier Bit 


Bit 8 of octet 1 is the Qualifier ('Q"') bit. It is used on SNA-to-SNA connections to 
identify ‘"Qualified’ data packets as described in "Logical Link Control (LLC) on 
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| SNA-to-SNA Connections" on page II-83. 


6.3.1.2 Delivery Confirmation Bit 


Bit 7 of octet 1 is the Delivery Confirmation bit. 


6.3.1.3 Packet Receive Sequence Number, Pr 


Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are the Packet 
Receive Sequence Number (Pr). Pr is binary coded and bit 6» or bit 2 when extended, is 
the low order bit. 


6.3.1.4 More Data Bit 


Bit 5 in octet 3, or bit 1 in octet 4 when extended, is the More Data mark ('M' bit) 
which: 
6 = 


"0" for no more data; and, 
‘l1' for more data. 


6.3.1.5 Packet Send Sequence Number, Ps 


Bits 4, 3 and 2 of octet 3, or bits 8 through 2 of octet 3 when extended, are the 
Packet Send Sequence Number (Ps). Ps is binary coded and bit 2 is the low order bit. 


6.3.1.6 User Data Field 
Bits following octet 3, or octet 4 when extended, contain user data. 


| Note: The User Data field field must contain an integral number of octets. 


6.3.2 DTE and DCE Interrupt Packets 


6.3.2.1 SNA-to-SNA Connections 


INTERRUPT packets are not allowed on SNA-to-SNA connections. 


6.3.2.2 SNA-to-non SNA Connections 


Figure 7 illustrates the format of DTE and DCE INTERRUPT packets. 
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Bits 
8 7 6 5 4 3 2 1 
Octet . 

1 General format identifier (CGFI) Logical channel group number 
2 Logical channel number 
3 Packet type identifier 

0 0 1 0 0 0 1 1 
4 Interrupt user data 


Note: GFI — Coded 0X01 (modulo 8) or 0X10 (modulo 128). 


Figure 7. DTE and DCE INTERRUPT: Packet Format 


6.3.2.3 Interrupt User Data Field 


Octet 4 contains user data. 


6.3.3  DTE and DCE Interrupt Confirmation Packets 


6.3.3.1 SHA-to-SNA Connections 


INTERRUPT CONFIRMATION packets are not allowed on SNA-to-SNA connections. 


6.3.3.2 SNA-to-non SNA Connections 


Figure 8 illustrates the format of DTE and DCE INTERRUPT CONFIRMATION packets. 


Bits 
8 7 6 5 4 3 2 1 
o ce tC et nee c - ? Ba NS ah ot tae PRA aay, eT Re Ss ie an ate 
1 eneral format identifier (GFI) Logical channel group number 
2 | Logical channel number 
3 


Packet type itdentifier 
0 0 


Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 8. DTE and DCE INTERRUPT CONFIRMATION: Packet Format 


6.4 DATAGRAM AND DATAGRAM SERVICE SIGNAL PACKETS 


DATAGRAM and DATAGRAM SERVICE SIGNAL packets are not allowed in IBM SNA X.25 DTEs. 


(Text deleted). 
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6.5 FLOW CONTROL AND RESET PACKETS 


6.5.1 DTE and DCE Receive Ready (RR) Packets 


Figure 93 illustrates the format of DTE and DCE RECEIVE READY packets. 
Bits 


8 7 6 5 4 3 2 1 
Octet 

1 General format identifier (GFI) Logical channel group number 

0 0 0 1 
2 Logical channel number 
3 Packet type identifier 

0 0 
(Modulo 8) 
Bits 
8 7 6 5 4 3 2 1 


Octet 
1 General format identifier (GFI) Logical channel group number 
rs | 
2 Logical channel number 


3 Packet type identifier 
0 0 


(Modulo 128) 


Figure 9. DTE and DCE RECEIVE READY: Packet Format 


6.5.4.1 Packet Receive Sequence Number, Pr 


Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are the Packet 


Receive Sequence Number (Pr). Pr is binary coded and bit 6, or bit 2 when extended, is 
the lcw order bit. 


6.5.2 DTE and DCE Receive Not Ready (RNR) Packet 


Figure 10 on page JII-60 illustrates the format of DTE and DCE RECEIVE NOT READY 
packets. 
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Bits 
8 7 6 5 4 3 2 1 


General format identifier (GFI) Logical channel group number 
0 0 0 1 


Octet 
1 


2 Logical channel number 


Packet type identifier 
0 1 0 


CModulo 8) 
Bits 
8 7 6 5 4 3 2 1 
Octet 
1 
2 
3 
4 


(Modulo 128) 


Figure 10. DTE and DCE RECEIVE NOT READY: Packet Format 


6.5.2.1 Packet Receive Sequence Number, Pr 


Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended; are the Packet 
Receive Sequence Number (Pr). Pr is binary coded and bit 6, or bit 2 when extended, is 
the low order bit. 


6.5.3 Reset Request and Reset Indication Packets 


Figure 11 illustrates the format of RESET REQUEST and RESET INDICATION packets. 


| Bits 
8 7 6 5 4 3 | 2 1 
Octet : . 

1 General format identifier (GFI) Logical channel group number 
2 Logical channel number 
3 Packet type identifier 

0 0 1 1 ~—~0 1 af 
4 Resetting cause 
5 Diagnostic code 


(This field is mandatory on SNA-to-SNA Connections 
Csee Attachemt F)) 
(Text deleted.) 
Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure ll. RESET REQUEST and RESET INDICATION: Packet Format 
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6.5.3.1 Resetting Cause Field 


Octet 4 is the Resetting Cause field and contains the reason for the reset. 


The bits of the Resetting Cause field in RESET REQUEST packets must be set to '0" by 
DTEs. 


(Text deleted. ) 


The coding of the Resetting Cause field in RESET INDICATION packets is given in Table 
II-1ll. 


Table II-11 — Coding of the Clearing Cause field 
in RESET INDICATION packets 


DTE Originated 


Out of orderx 

Remote procedure error 
Local procedure error 
Network congestion 

Remote DTE operational * 
Network operational * 
Incompatible destination* 


eoDdoaqgao0oo0oaqa !], ol oe 
eaQodocreqood0 | oe 
eEooaoaoo0deo!| o 
KR OaaQaoaooo | oo 
COrFRrFMOCOCOO!]Oo! & 
Or OrFrH OO] ©] Ww 
OM OrRMOrFO | © | NM 
fad ft fe ee pd per ter | > | be 


* Applicable to permanent virtual circuits only. 
DEC — decimal 


6.5.3.2 Diagnostic Code 


Octet 5 is the Diagnostic Code field (mandatory on SNA-to-SNA connections) and 
contains additional information on the reason for the reset. 


Diagnostic Codes generated by IBM SNA X.25 DTEs for RESET REQUEST packets on 
SNA-to-SNA connections are shown in Table F-1. 


In a RESET INDICATION packet, if the Resetting Cause field indicates "DTE Originated”, 
the Diagnostic Code has been passed unchanged from the remote DTE. If the DTE 
requesting a reset has not provided a Diagnostic Code in its RESET REQUEST packet, the 
bits of the Diagnostic Code in the resulting RESET INDICATION packet are "0°. 


If a RESET INDICATION packet results from a RESTART REQUEST packet, the value of the 
Diagnostic Code will be that specified in the RESTART REQUEST, or '0" in the case where 
no Diagnostic Code has been specified in RESTART REQUEST packets. 


If the Resetting Cause field does not indicate "DTE Originated", the Diagnostic Code 
in RESET INDICATION packets is network generated. Appendix E lists the codings for 
network generated diagnostics. The Diagnostic Code field is set to '0° when no 
specific additional information on the reason for the reset is supplied. 


Note: The contents of the Diagnostic Code field do not alter the meaning of the Cause 
field. IBM SNA X.25 DTEs must report the contents of the Diagnostic Code and Resetting 
Cause fields to a higher layer. DTEs shall not refuse to accept the Cause field 
because the Diagnostic Code field contains an unspecified code combination. 


6.5.4 DTE and DCE Reset Confirmation Packets 


Figure 12 on page II-62 illustrates the format of DTE and DCE RESET CONFIRMATION 
packets. , 
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Bits 


8 7 6 5 4 3 2 1 
Octet : , , | 
1 General format identifier (GFI) Logical channel group number 
2 Logical channel number 
3 wpeakes type identifier 
- aye 1 


Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 12. DTE and DCE RESET CONFIRMATION: Packet Format 


6.6 RESTART PACKETS 


6.6.1 Restart Request and Restart Indication Packets 


Figure 13 illustrates the format of RESTART REQUEST and RESTART INDICATION packets. 


Bits 
8 7 6 5 4 3 2 1 
Octet 
1 General format identifier (GFI) Logical channel group number 
0 0 0 0 
2 Logical channel number 
0 
3 Packet type identifier 
1 1 1 

4 
5 


Diagnostic code 
CThis field is mandatory on SNA~to~-SNA Connections 
(see Appendix F)) 


H (Text deleted.) 
Notes: GFI ~— Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 13. RESTART REQUEST and RESTART INDICATION: Packet Format 


6.6.1.1 Restarting Cause Field 


Octet 4 is the Restarting Cause field and contains the reason for the restart. 


The bits of the Restarting Cause field in RESTART REQUEST packets are set to "0° by IBM 
SNA X.25 DTEs. (Text deleted). 


The coding of the Restarting Cause field in RESTART INDICATION packets is given in 
Table II-12. 
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Table II-12 — Coding of the Restarting Cause field 
in RESTART INDICATION packets 


DEC — decimal 


6.6.1.2 Diagnostic Code 


Octet 5 contains the Diagnostic Code which provides additional information on the 
reason for the restart. 


Diagnostic Codes generated by IBM SNA X.25 DTEs for RESTART REQUEST packets on 
SNA-to-SNA connections are given in Table F-l. The Diagnostic Code is passed to the 
corresponding DTEs as the Diagnostic Code of a RESET INDICATION packet on permanent 
virtual circuits or a CLEAR INDICATION packet on virtual calls. 


The coding of the Diagnostic Code field in a RESTART INDICATION packet 1s given in 
Appendix E. The contents of the Diagnostic Code field is set to '0" when no specific 
additional information on the reason for the restart is supplied. 


Note: The contents of the Diagnostic Code field do not alter the meaning of the Cause 
field. IBM SNA X.25 DTEs must report the contents of the Diagnostic Code field to a 
higher layer. DTEs shall not refuse to accept the Cause field because the Diagnostic 
Code field contains an unspecified code combination. 


6.6.2 DTE and DCE Restart Confirmation Packets 


Figure 14 illustrates the format of DTE and DCE RESTART CONFIRMATION packets. 


Bits 
8 7 6 5 4 3 2 1 


Octet 
1 


Note: GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 14. DTE and DCE RESTART CONFIRMATION: Packet Format 


6.7 DIAGNOSTIC PACKETS 


Figure 15 on page II-64 illustrates the format of DIAGNOSTIC packets. 


PACKET FORMATS 3 TI-63 


SNA/X.25 DTE/DCE Interface 


| Bits / 
8 7 6 5 4 3 2 | 1 
Octet : 
1 General format identifier (GFI)}] Logical channel group number 
0 0 
2 Logical channel number 
3 Packet type identifier 
: 1 1 0 
: 
5 
: | Diagnostic explanation (see Note 2) | | 
n 


WERE a sree Re a eS ee Nee ee CT TE EE EE ee 


Figure 15. DIAGNOSTIC: Packet Format 
Notes te Figure 15: 
1. GFI - Coded 0001 (modulo 8) or 0010 (modulo 128). 


2. The diagnostic explanation field is required to be an integral number of octets in 
length. | 


6.7.1 Diagnostic Code Field 


Octet 4 contains the diagnostic code and provides information on the error condition 
that resulted in the transmission of the DIAGNOSTIC packet. Diagnostic Codes are 
given in Appendix E. 


6.7.2 Diagnostic Explanation Field 


When the DIAGNOSTIC packet is issued, by DCEs, as a result of receiving an erroneous 
packet from the DTE (see Table C-1), this field contains the first three octets of 
header information from the erroneous DTE packet. If the packet contains less than 3 
octets, this field contains whatever bits were received. 


When the DIAGNOSTIC packet is issued as a result of a DCE time-out (see Table D-1), the 
Diagnostic Explanation field contains 2 octets coded as follows: 


e Bits 8,» 7, 6 and 5 of the first octet contain the General Format Identifier for the 
DTE/DCE interface. | 


e Bits 4 to 1 of the first octet and bits 8 to 1 of the second octet are x'000' for 
expiration of time-out 710; and, give the identifier of the logical channel on 
which the time-out occurred for expiration of time-out T12 or T13. 


6.8 PACKETS REQUIRED FOR OPTIONAL USER FACILITIES 
6.8.1 DIE Reject (REJ) Packet for the Packet Retransmission Facility 


The packet retransmission facility 71S not used in SNA environments. Therefore, DTE 
REJECT packets are not generated by IBM SNA X.25 DTEs. 


(Text deleted). 
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6.8.2 Call Set-up and Clearing Packets for the Fast Select Facilities 


6.8.2.1 SNA-to-SNA Connections 


The possible use of Fast Select facilities on SNA-to-SNA connections is a subject for 
further study. 


6.8.2.2 SNA-to-non_SNA Connections 


Figure 16 illustrates the format of CALL REQUEST and INCOMING CALL packets used in 
conjunction with the Fast Select facility and Fast Select Acceptance facility 
described in "Fast Select" on page II-75 and "Fast Select Acceptance" on page II-76. 


The description in “Call Request and Incoming Call Packets” on page II-50 applies 
here, except that the call user data field has a maximum length of 128 octets. 


Note: At present, some networks require the call user data field to contain an 
integral number of octets (see "DESCRIPTION OF THE PACKET LEVEL DTE/DCE INTERFACE" on 
page II-24%, Note 2). 


Bits 
8 7 6 5 4 3 2 1 


Octet 
1 


General format identifier (GFI) Logical channel group number 


2 Logical channel number 
3 Packet type identifier 

0 0 0 0 1 0 1 1 
4 Calling DTE address length Called DTE address length 


r DTE address (see Note 2) 


Facilities 


n Call user data (see Notes 3 and 4) 


Figure 16. CALL REQUEST and INCOMING CALL: Packet Format for the Fast Select 
facility 


Notes to Figure 16: 
1. GFI'- Coded 0X01 Cmodulo 8) or 0X10 (modulo 128). 


2.. The figure is drawn assuming a single address is present consisting of an odd 
number of digits. 


3. Bits 8 and 7 of the first setae: of the call user data field may have particular 
Significance (see "Call Request and Incoming Call Packets" on page IJI-50). 


4. Maximum length of the call user data field is 128 Octets. 
Figure 17 on page II-66 illustrates the format of CALL ACCEPTED and CALL CONNECTED 
packets used in conjunction with the Fast Select facility and Fast Select Acceptance 


ae described in "Fast Select” on page II~-75 and "Fast Select Acceptance" on page 
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Bits 
8 7 6 5 4 3 2 1 
Octet : 
1 General format identifier (GFI) Logical channel group number 
2 Logical channel number 
3 sperner eee | 
4 Calling DTE address length Called DTE address length 


3 DTE address (see Note 2) 


Facilities ~ 


n Call user data (see Notes 3 and 4) 


Figure 17. CALL ACCEPTED and CALL CONNECTED: Packet Format for the Fast Select 
facility 


Notes to Figure 17: 
1. GFI - Coded 0X01 (modulo 8) or 0X10 Cmodulo 128). 


2. The figure is drawn assuming a single address is present consisting of an odd 
number of digits 


3. Bits 8 and 7 of the first octet of the call user data field may have particular 
Significance (see "Call Request and Incoming Call Packets" on page II-50). 


4. Maximum length of the call user data field is 128 Octets. 


The description in "Call Accepted and Call Connected Packets" on page II-52 applies 
here and, in addition, the called user data field may be present and has a maximum 
length of 128 octets. The address lengths field and facility Length field are 
mandatory. 


Note: At present, some networks require the called user data field to contain an 
integral number of octets (see "DESCRIPTION OF THE PACKET LEVEL DTE/DCE INTERFACE" on 
page II-24, Note 2). 


If the called user data field jis present, the use and format of this field is 
determined by bits 8 and 7 of the first octet of this field (see Note below). 


If bits 8 and 7 of the first octet of the called user data field are '00', a portion of 
the called user data field is used for protocol identification in accordance with 
other Recommendations. | 


If bits 8 and 7 of the first octet of the called user data field are '01', a portion of 
the called user data field is used for protocol identification in accordance with 
specifications of Administrations. 


If bits 8 and 7 of the first octet of the called user data field are '10'", a portion of 
the called user data field may be used for protocol identification in accordance with 
specifications of international user bodies. 


If bits 8 and 7 of the first octet of the called user data field are "1l1', no 


cae take are placed on the use by the DTE of the remainder of the called user data 
ield. 


Users are cautioned that if bits 8 and 7 of the first octet of the called user data 
field have any value other than '‘11', a protocol may be identified that is implemented 
within public data networks. 
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Note: When a virtual call is being established between two packet mode DTEs, the 
network does not act on any part of the called user data field. 


Figure 18 illustrates the format of CLEAR REQUEST and CLEAR INDICATION packets used in 
conjunction with the Fast Select facility and Fast Select Acceptance facility 
described in "Fast Select" on page [I-75 and "Fast Select Acceptance" on page II-76. 


Bits 

8 7 6 5 G 3 2 1 
Octet 

1 General format identifier (GFI) Logical channel group number 

2 Logical channel number 

3 Packet type identifier 

0 0 0 1 0 0 1 1 

6 Calling DTE address length Called DTE address length 

‘ | DTE address (see Note 2) 

7 Facilities 

n Call user data (see Notes 3) 


Figure 18. CLEAR REQUEST and CLEAR INDICATION: Packet Format for the Fast 
Select facility 


Notes to Figure 18: 
1. GFI - Coded 0X01 (modulo 8) or 0X10 (modulo 128). 


2. The figure 1s drawn assuming a single address is present consisting of an odd 
number of digits. 


3. Maximum length of the call user data field is 128 octets. 
Description of the clearing cause field and the diagnostic code field in "Clear 
Request and Clear Indication Packets" on page II-54 apply here. In addition the 
following fields may follow the diagnostic code field and in such cases the use of the 
diagnostic code field is mandatory. 
1. Address lengths field 
Octet 6 consists of field length indicators for the called and calling DTE 
addresses. Bits 4, 3, 2 and 1 indicate the length of the called DTE address in 
semi-~octets. Bits 8, 7, 6 and 5 indicate the length of the calling DTE adcress in 


semi-~octets. Each address length indicator is binary coded and bit 1 or 5 is the 
low order bit of the indicator. 


Note: This field is coded with all "0's. Other codings are for further study. 
2. Address field 
Note: Pending the further study indicated above, this field is not present. 


3. Facility length field 
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Bits 6, 5, 4, 3, 2 and 1 of the octet following the address field indicate the 
length of the facility field in octets. The facility length indicator is binary 
coded and bit 1 is the low order bit of the indicator. 


Bits 8 and 7 of this octet are unassigned and set to 0. 


Note: This field is coded with all "O's. Other codings are for further study. 
Facility field 


Note: Pending the further study indicted above, this field is not present. 
Clear user data field 
Following the facility field, the clear user data field may be present and has a 


maximum length of 128 octets. 


Note: At -present, some networks require the clear user data field to contain an 
integral number of octets (see "DESCRIPTION OF THE PACKET LEVEL DTE/DCE INTERFACE" 
on page JI-24, Note 2). 
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7.0 PROCEDURES AND FORMATS FOR OPTIONAL USER FACILITIES 
7.1 PROCEDURES FOR OPTIONAL USER FACILITIES ASSOCIATED WITH VC SERVICES 


7.1.1 Extended Packet Sequence Numbering 


Extended Packet Sequence Numbering is an optional user facility agreed upon for a 
period of time. It applies in common to all logical channels at the DTE/DCE interface. 


This user facility, if subscribed to, provides sequence numbering of packets performed 
modulo '128'. In the absence of this facility, the sequence numbering of packets is 
performed modulo '8’*. 


7.1.2 Non-Standard Default Window Sizes 


Non-standard Default Window Sizes is an optional user facility agreed upon for a 
period of time. The ability to select this facility must be provided by IBM SNA X.25 
DTEs. This user facility, if subscribed to, provides for the selection of default 
window sizes from the List of window sizes supported by the network. Some 
Administrations may constrain the default window sizes to be the same for each 
direction of data transmission across the DTE/DCE interface. In the absence of this 
facility,.-the default window sizes are two (2). 


Values other than the default window sizes may be negotiated for virtual calls, ona 
per call basis, by means of the Flow Control Parameter Negotiation facility (see "Flow 
Control Parameter Negotiation" on page JI-73), which is recommended for implementation 
by IBM SNA X.25 DTEs. Values other than the default window sizes may be agreed upon 
for a period of time for each permanent virtual circuit. (Text deleted). 


7.1.3 Default Throughput Classes Assignment 


Default Throughput Class Assignment 1s an optional user facility agreed upon for a 
period of time. This user facility, if subscribed to, provides for the selection of 
default throughput classes from the list of throughput classes supported by the 
network. Some Administrations may constrain the default throughput classes to be the 
same for each direction of data transmission. In the absence of this facility, the 
default throughput classes correspond to the user class of service of the DTE (see 
"Coding of Throughput Class Negotiation Facility” on page JI-81) but do not exceed the 
maximum throughput class supported by the network. 


The default throughput classes are the maximum throughput classes which may be 
associated with any virtual call at the DTE/DCE interface. Values other than the 
default throughput classes may be negotiated for a virtual call by means of the 
Throughput Class Negotiation facility (see "Throughput Class Negotiation™ on page 


II-74). Values other than the default throughput classes may be agreed upon for a 
period of time for each permanent virtual. circuit. 


7.1.4 Packet Retransmission 

The packet retransmission facility is not used in SNA environments. 
(Text deleted). 

7.1.5 Incoming Calls Barred 


Incoming Calls Barred is an optional user facility agreed upon for a period of time. 
This facility applies to all logical channels at the DTE/DCE interface used for 
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virtual calls (Text deleted). This user facility, if subscribed to, prevents virtual 
calls (text deleted) from being presented to the DTE. The DTE may originate outgoing 
virtual calls (text deleted) only. 


Notes Logical channels used for virtual calls retain their full duplex capability. 
(Text deleted). 


7.1.6 ®@Qutgoing Calls Barred 


Outgoing Calls Barred is an optional user facility agreed upon for a period of time. 
This facility applies to all logical channels at the DTE/DCE interface used for 
virtual calls (text deleted). 


This user facility, if subscribed to, prevents the DCE from accepting outgoing virtual 
calls (text deleted) from the DTE. DTEsS may receive incoming virtual calls (text 
deleted). 


Note: tlogical channels used for virtual calls retain their full duplex capability. 


7.1.7 One-Way Logical Channel Outgoing 


One-way Logical Channels Outgoing is an optional user facility agreed upon for a 
period of time and is recommended for IBM SNA X.25 DTEs that support multiple virtual 
circuits. This user facility, if subscribed to, restricts logical channel use to 
originating outgoing virtual calls (text deleted) only. 


Note: A logical channel used for virtual calls retains its full duplex capability. 
(Text deleted). 


The rules according to which logical channel group numbers and logical channel numbers 
can be assigned to one-way outgoing logical channels for virtual calls are given in 
Appendix A. 


Note: If all the logical channels for virtual calls (text deleted) are one-way 
outgoing at a DTE/DCE interface, the effect is equivalent to the Incoming Calls Barred 
facility Csee "Incoming Calls Barred” on page II-69). 


7.1.8 One-Way Logical Channel Incoming 


One-way Logical Channels Incoming jis an optional user facility agreed upon for a 
period of time. This user facility, if subscribed to, restricts logical channel use 
to receiving incoming virtual calls (text deleted) only. This facility is recommended 
for IBM SNA X.25 DTEs that support multiple virtual circuits. 


Note: A legical channel used for virtual calls retains its full duplex capability. 


The rules according to which logical channel group numbers and logical channel numbers 
can be asstgned to one-way logical channels for virtual calls are given in Appendix A. 


Note: If all logical channels for virtual calls are one-way incoming at a DTE/DCE 
interface, the effect is equivalent to the Outgoing Calls Barred facility (see 
"Outgoing Calls Barred"). 


PROCEDURES AND FORMATS FOR OPTIONAL USER FACILITIES | II-70 


SNA/X.25 DTE/DCE Interface 


7.z.% Closed User Group 


Closed User Group is an optional user facility agreed upon for a period of time for 
virtual calls (text deleted). This facility, if subscribed to, enables the DTE to 
belong to one or more closed user groups, and is recommended for IBM SNA X.25 DTEs. A 
closec’ user group permits the DTEs belonging to the group to communicate with each 


other, but precludes communication with all other DTEs. 


The calling/source DTE should specify the closed user group selected for a virtual 
call (text deleted) using the optional user facility parameters (see "Coding of Closed 
User Group Facility™ on page II-79) in the CALL REQUEST (text deleted) packet. 


The closed user group selected for a virtual call (text deleted) will be indicated to a 
called/destination DTE using the optional user facility parameters (see "Coding of 
Cilesed User Group Facility” on page II-79) in the INCOMING CALL (text deleted) packet. 


When a DTE only belongs to one closed user group or when the virtual call (text 
deleted) is associated with the DTE's preferential closed user group, this indication 
may not be present in the CALL REQUEST or INCOMING CALL (text deleted) packet. 


IBM SNA X.25 DTEs that support a single CLOSED USER GROUP require no coding in the 


facilities field when the PSDN supports the assignment of a default user group. 


7.3.10 Closed User Group with Outgoing Access 


Clesed User Group with Outgoing Access is an optional user facility agreed upon for a 
period of time for virtual calls (text deleted). This facility, tf subscribed to, 
enables the DTE to belong to one or more closed user groups (as in "Closed User Group™) 
and to originate virtual calls (text deleted) to DTEs in the open part of the network 
and to DTEs having the incoming access capability. This facility is recommended for 
IBM SNA X.25 DTEs that support multiple virtual circuits. 


The procedures for using this facility are the same as those given in "Closed User 
Group." However, the optional user facility parameters may not be present when 
originating virtual calls (text deleted) to DITEs in the open part of the network or to 
DTIEs having the incoming access capability. 


7.1.11 Closed User Group with Incom:ng Access 


Closed User Group with Incoming Access 15 an optional user facility agreed upon for a 
pertod of time for virtual calls (text deleted). This facility, if subscribed to, 
enables the DTE to belong to one or more closed user groups (as in "Closed User Group") 
amd to receive incoming calls (text deleted) from DTEs in the open part of the network 
and from DTEs having the outgoing access capability. 


The procedures for using this facility are the same as those given in "Closed User 
Group. However, the optional user facility parameters may not be present when 
receiving incoming calls (text deleted) from DTEs in the open part of the network or 
from DTEs having the outgoing access capability. This facility is recommended for IBM 
SNA X.25 DTEs that support multiple virtual circuits. 


7.4.12 Incoming Calls Barred Within a Closed User Group 


Imcoming Calls Barred within a Closed User Group is an optional user facility agreed 
upon for a period of time. This user facility, if subscribed to for a given closed 
user group, permits the DTE to originate virtual calls (text deleted) to DIEs in this 
closed user group, but precludes the reception of incoming calls (text deleted) from 
other DTEs in this closed user group. 


The procedures for using this facility are the same as those given in "Closed User 


Group,” "Closed User Group with Outgoing Access™ and "eoaee User Group with Incoming 
Access." 
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7.1.13 Outgoing Calls Barred within a Closed User Group 


Outgoing Calls:Barred within a Closed User Group is an optional facility agreed upon 
for a period of time. This user facility, if subscribed to for a given closed user 
group, permits the DTE to receive virtual calls (text deleted) from other DTEs in this 
closed user group, but prevents the DTE from originating virtual calls (text deleted). 
to other DTEs in this closed user group. 


The procedures for using this facility are the same as those given in "Closed User 


Group™ on page II-71, "Closed User Group with Outgoing Access™ on page IJI-71 and 
"Closed User Group with Incoming Access" on page II-71. 


7.1.14 Bilateral Closed User Group 


Bilateral Closed User Groups are not supported in SNA environments. 


(Text deleted). 


7.1.15 Bilateral Closed User Group with Outgoing Access 


Bilateral Closed User Groups with Outgoing Access are not supported in SNA 
environments. 


(Text deleted). 


7.1.16 Reverse Charging 


Reverse Charging is an optional user facility which can be requested by a DTE for a 
given virtual call (text deleted) (see "Coding of Reverse Charging Facility" on page 
II-79). This facility is recommended for IBM SNA X.25 DTEs. 


7.1.17 Reverse Charging Acceptance 


Reverse Charaing Acceptance is an optional user facility agreed upon for a period of 
time. 


This user facility, if subscribed to, authorizes the DCE to transmit to the DTE 
incoming calls (text deleted) which request the Reverse Charging facility. In the 
absence of this facility, the DCE will not transmit to the DTE incoming calls (text 
deleted) which request the Reverse Charging facility. This facility is recommended 
for IBM SNA X.25 DTEs. 


7.1.18 RPOA Selection 


RPOA (Recognized Private Operating Agency) selection is an optional user facility 
which can be requested by a DTE for a given virtual call (text deleted). 


This user facility, when requested, provides for the user specification by the 
calling/source DTE of a particular RPOA transit network through which the call (text 
deleted) is to he routed internationally, when more that one RPOA transit network 


ens at an international gateway (see "Coding of RPOA Selection Facility™ on page 
~80). 


7.2 _ PROCEDURES FOR OPTIONAL USER FACILITIES ONLY AVAILABLE WITH VC SERVICES 
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7.2.1 WNon-Standard Default Packet Sizes 


Non-standard Default Packet Sizes is an optional user facility agreed upon for a 
period of time. The ability to select this facility must be provided by IBM SNA X.25 
DTEs. This facility, if subscribed to, provides for the selection of default packet 
sizes from the list of packet sizes supported by the network. Some network 
Administrations may constrain packet sizes to be the same for each direction of data 
transmission across the DTE/DCE interface. In the absence of this facility, default 
packet sizes are '128' octets. | 


Note: In "Non-Standard Default Packet Sizes," the term “packet sizes" refers to the 
maximum User Data field lengths of DCE DATA and DTE DATA packets. 


Values other than the default packet sizes may be negotiated for a virtual call, ona 
per call basis, by means of the flow control parameter negotiation facility (see "Flow 
Control Parameter Negotiation"), which may be implemented in IBM SNA X.25 DTEs. 
Values other than the default packet sizes may be agreed upon for a period of time for 
each permanent virtual circuit. 


7.2.2 Flow Control Parameter Negotiation 


Flow Control Parameter Negotiation is an optional user facility agreed upon for a 
period of time which can be used by a DTE for virtual calls. The ability for the DTE 
to select this facility is recommended for IBM SNA X.25 DTEs. This facility, if 
subscribed to, permits negotiation, on a per call basis, of flow control parameters. 
The flow control parameters considered are the packet and window sizes at the DTE/DCE 
interface for each direction of data transmission. 


Note: In "Flow Control Parameter Negotiation,™ the term "packet sizes" refers to the 
maximum User Data field lengths of DCE DATA and DTE DATA packets. 


In the absence of the Flow Control Parameter Negotiation facility, the flow control 
parameters to be used at a particular DTE/DCE interface are the default packet sizes 
(see "Non-Standard Default Packet Sizes") and the default window sizes (see 
"Non-Standard Default Window Sizes" on page II-639). 


When the calling DTE has subscribed to the Flow Control Parameter Negotiation 
facility, it may separately request packet sizes and window sizes for each direction 
of data transmission (see "Coding of the Flow Control Parameter Negotiation Facility" 
on page II-80). If a particular window size is not explicitly requested ina CALL 
REQUEST packet, the DCE will assume that the default Window size was requested. Ifa 
particular packet size is not explicitly requested, the DCE will assume that the 
default packet size was requested. 


When a called DTE has subscribed to the Flow Control Parameter Negotiation facility, 
each INCOMING CALL packet indicates the packet and window sizes from which negotiation 
starts. No relationship needs to exist between the packet sizes (P) and window sizes 
(W) requested in the CALL REQUEST packet and those indicated in the INCOMING CALL 
packet.’ The called DTE may request window and packet sizes with facilities in the CALL 
ACCEPTED packet. The only valid facility requests in the CALL ACCEPTED packet, as a 
function of the facility indications in the INCOMING CALL packet, are given in Table 
II-13. If the Facility request is not made in the CALL ACCEPTED packet, the DTE is 
assumed to have accepted the indicated values (regardless of the default values). 
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TABLE II-13 —- Valid facility requests in CALL ACCEPTED packets in 
response to facility indications in INCOMING CALL packets 


Facility Indication Valid Facility Request 


W Cindicated) 2 2 W Cindicated) 2 W Crequested) 2 2 
W Cindicated) = 1 W Crequested) = 1 or 2 


P Cindicated) 2 128 P Cindicated) 2 P Crequested) 2 128 
P Cindicated) < 128 128 2 P Crequested) 2 P Cindicated) 


When the calling DTE has subscribed to the Flow Control Parameter Negotiatior 
facility, every CALL CONNECTED packet indicates the packet and window sizes used at 
the DTE/DCE interface for the call. The only valid facility indications in the CALL 
CONNECTED packet, as a function of the facility requests in the CALL REQUEST packet, 
are given in Table II-14. 


TABLE II-14 — Valid facility indications in CALL CONNECTED packets in 
response to facility request in CALL REQUEST packets 


Facility Request Valid Facility Indication : 


W Crequested) 2 W Cindicated) 2 2 
W Cindicated) = 1 or 2 


P Crequested) 2 P Cindicated) 2 128 
128 => P Cindicated) 2 P Crequested) 


The network may have constraints requiring the flow control parameters used for a call 
to be modified before indicating them to the DTE in the INCOMING CALL packet or CALL 
CONNECTED packet; e.g., the ranges of parameter values available on various networks 
may differ. 


Crequested) 2 
Crequested) 


AIV 


Crequested) 
Crequested) 


Window and packet sizes need not be the same at each end of a virtual call. 


The role of the DCE in negotiating the flow control parameters may be network 
dependent. 


7.2.3 Throughput Class Negotiation 


Throughput class negotiation is an optional user facility agreed upon for a period of 
time which can be used by a DTE for virtual calls. This facility, if subscribed to, 
permits negotiation, on a per call basis, of the throughput classes; and, should be 
supported by IBM SNA X.25 DTEs that support multiple virtual circuits. The throughput 
classes are considered independently for each direction of data transmission. 


Default values are agreed upon between the DTE and the Administration (see "Default 
Throughput Classes Assignment” on page II-69). The default values correspond to the 
maximum throughput classes which may be associated with any virtual call at the 
DTE/DCE interface. 


When the calling DTE has subscribed to the Throughput Class Negotiation facility, it 
may separately request the throughput classes of the virtual calls in the CALL REQUEST 
packet (see "Coding of Throughput Class Negotiation Facility" on page II-81). If 
particular throughput classes are not requested, the DCE will assume the default 
values. 


When a called DTE has subscribed to the Throughput Class Negotiation facility, each 
INCOMING CALL packet indicates the throughput classes from which negotiation may 
starts. Fhese throughput classes are lower or equal to the ones selected at the 
calling DTE/DCE interface, either explicitly, or by default if the calling DTE has not 
subscrited to the Throughput Class Negotiation facility or has not explicitly 
requested throughput class values in the CALL REQUEST packet. These throughput 
classes tndicated to the called DTE will also not be higher than the default 
throughput classes, respectively, for each direction of transmission, at the calling 
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and the called DTE/DCE interfaces. They may be further constrained by internal 
limitations of the network. 


The called DTE may request with a facility in the CALL ACCEPTED packet the throughput 
classes that should finally apply to the virtual call. The only valid throughput 
classes in the CALL ACCEPTED packet are lower than or equal to the ones (respectively) 
indicated in the INCOMING CALL packet. If the called DTE does not make any throughput 
class facility request in the CALL ACCEPTED packet, the throughput classes finally 
applying to the virtual call will be the ones indicated in the INCOMING CALL packet. 


If the called DTE has not subscribed to the Throughput Class Negotiation facility, the 
throughput classes finally applying to the virtual call are less than or equal to the 
ones selected at the calling DTE/DCE interface, and less than or equal to the default 
values defined at the called DTE/DCE interface. 


When the calling DTE has subscribed to the Throughput Class: Negotiation facility, 
every CALL CONNECTED packet will indicate the throughput classes finally applying to 
the virtual call. 


When neither the calling DTE nor the called DTE has subscribed to the Throughput Class 
Negotiation facility, the throughput classes applying to the virtual call will not be 
higher than the ones agreed as defaults at the calling and called DTE/DCE interfaces. 
They may be further constrained to lower values by the network, e.g., for 
international service. 


Note: 


1. {Since both Throughput Class Negotiation and Flow Control Parameter Negotiation 
Csee "Flow Control Parameter Negotiation™ on page II-73) facilities can be applied 
to a uh et ac the achievable throughput will depend on how users manipulate 
the 'D' bit. 


2. Users are cautioned that the choice of too small a window and packet size at a 
DTE/DCE interface (made by use of the Flow Control Parameter Negotiation facility) 
may adversely affect the attainable throughput class for a virtual call. This is 
likewise true of flow control mechanisms adopted by the DTE to control data 
transmission from the DCE. 


7.2.% Fast Select 


7.2.%.1 SNA-tO-SNA Connections 


The possible use of the Fast Select facility on SNA-to-SNA connections is a subject 
for further study. 


7.2.%.2 SNA-to-non_SNA Connections 


Fast select is an optional user facility which may be requested by a DTE for a given. 
virtual call. 


DTEsS can request the fast select facility on a per call basis by means of an 
appropriate request (see "Coding of Fast Select Facility" on page II-82) ina CALL 
REQUEST packet using any logical channel which has been assigned to virtual calls. 


The fast select facility, if requested in the CALL REQUEST packet and if it indicates 
no restriction on response, allows this packet to contain a call user data field of up 
to 128 octets and authorizes the DCE to transmit to the DTE, during the DTE waiting 
state, a CALL CONNECTED packet with a called user data field of up to 128 octets ora 
CLEAR INDICATION packet with a clear user data field of up to 128 octets. 


The fast select facility, is requested in the CALL REQUEST packet and if it indicates 
restriction on response, allows this packet to contain a call user data field of up to 
128 ectets and authorizes the DCE to transmit to the DTE, during the DTE waiting state, 
a CLEAR INDICATION packet with a clear user data field of up to 128 octets; the DCE 
would not be authorized to transmit a CALL CONNECTED packet. 
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Where a DTE requests the Fast Select facility in a CALL REQUEST packet, the INCOMING 
CALL packet should be only delivered to the called DTE if that DTE has subscribed to 
the fast select acceptance facility (see "Fast Select Acceptance”). 


If the called DTE has subscribed to the fast select acceptance facility, it will be 
advised that the fast select facility, and an indication of whether or not there isa 
restriction on the response, has been requested through the inclusion of the 
appropriate facility in the INCOMING CALL packet. 


If the called DTE has not subscribed to the fast select acceptance facility, an 
INCOMING CALL packet with the fast select facility requested will not be transmitted 
and a CLEAR INDICATION packet with the cause "Fast select acceptance not subscribed" 
will be returned to the calling DTE.: 


The presence of the fast select facility indicating no restriction on response in an 
INCOMING CALL packet permits the DTE to issue as a direct response to this packet a 
CALL ACCEPTED packet with a called user data field of up to 128 octets or a CLEAR 
REQUEST packet with a clear user data field of up to 128 octets. 


The presence of the fast select facility indicating restriction on response in an 
INCOMING CALL packet permits the DTE to issue as a direct response to this packet a 
CLEAR REQUEST packet with a clear user data field of up to 128 octets; the DTE would 
not be authorized to send a CALL ACCEPTED packet. 


The possibility to send a CLEAR REQUEST packet with a clear user data field up to 128 
octets at any time instead of just in the DCE Waiting state (p3) is for further study. 


Note: The call user data field, the called user data field and the clear user data 
field will not be fragmented for delivery across the DTE/DCE interface. 


The significance of the CALL CONNECTED packet and the CLEAR INDICATION packet with the 
cause "DTE originated" as a direct response to the CALL REQUEST packet with the fast 
select facility is that the CALL REQUEST packet with the data field has been received 
by the called DTE. 


All other procedures of a call in which the fast select facility has been requested are 
the same as those of a virtual call. . 


If a fast select CLEAR REQUEST packet with a non-zero Address Length field or Facility 
Length field is received, the DCE shall discard the received packet. The DCE shall 
indicate clearing by transmitting to the DTE a CLEAR INDICATION packet with the cause 
"Local procedure error™ and diagnostic No. 81 or No. 82, as appropriate; the DCE shall 
consider the clearing procedure complete and enter state pl. The distant DTE is also 
informed of the clearing by a CLEAR INDICATION packet, with the cause "Remote 
procedure error” €same diagnostic). 


7.2.5 Fast Select Acceptance 


7.2.5.1 SNA-to-SNA Connections 


The possible use of the Fast Select Acceptance in SNA environments is a-subject for 
further study. 


7.2.5.2 SNA-to-non_SNA Connections 


Fast select acceptance is an optional user facility agreed for a period of time. This 
user facility, if subscribed to, authorizes the DCE to transmit to the DTE INCOMING 
CALL packets which request the fast select facility. In the absence of this facility, 
the rity will not transmit to the DTE incoming calls’ which request the fast select 
facility. 
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7.2.6 ‘*D" Bit Modification 


Use of the 'D' bit Modification facility is not allowed in SNA environments. 


(Text deleted). 


7.3 PROCEDURES FOR OPTIONAL USER FACILITIES ONLY AVAILABLE WITH DATAGRAM SERVICES 


Datagram services are not used in SNA environments. 


(Text deleted). 
7.% FORMATS FOR OPTIONAL USER FACILITIES 


7.%.1 General 


The Facility field is present only when a DTE is using an optional user facility 
requiring some indication in CALL REQUEST, INCOMING CALL, CALL ACCEPTED, CALL 
CONNECTED, CLEAR REQUEST or CLEAR INDICATION (text deleted) packets. 

The Facility field contains one or more facility elements. The first octet of each 
facility element contains a facility code to indicate the facility or facilities 
requested. 

Note: A facility code must not appear more than once in SNA environments. 

The facility codes are divided into four classes, by making use of bits 8 and 7 of the 
facility field, to specify facility parameters consisting of ‘1l', "2", '3', ora 


variable number of octets. The general class coding of the facility code field is 
shown in Table II-15. 


Table II-15 —- Facility code field class coding 


pool ore Pts es] TERRE 
CLASS} 8765 4321 Characteristics 

Da [oexx xxxx| sinoie octet 
Te [eixx xxxx| dovble octet 
To [aa xx xxx x] varieble tensth 


For class '"D’ the octet following the facility code indicates the length, itn octets, 
of the facility parameter field. The facility parameter field length 1s binary coded 
and bit 1 is the low order bit of this indicator. Formats for the four classes are 
shown in Table IJI-16. 
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CLASS A CLASS B 


Bits 8 7 Bits 8 
Octet : Octet 
0 


Facility parameter 


field 


CLASS C | cas 
Bits 8 7 6 5 4 3 2 Bits 8 


Octet Octet 
0 0 X X X X X X 
Facility Facility parameter 
field length 
parameter 
Facility 


field 
parameter 


field 


The facility code field is binary coded and, without extension, provides for a maximum 
of 64 facility codes for classes 'A', "B" and 'C’ and '63!' facility codes for class 'D’ 
giving a total of '255' facility codes. 


Facility code x'FF" is reserved for extension of the facility code. The octet 
following this octet indicates an extended facility code having the format 'A't, 'B', 
'C" or 'D’ as defined above. Repetition of facility code x'FF' 1s permitted and thus 
additional extensions result. 


The coding of the facility parameter field 1s dependent on the facility being 
requested. 


A facility code may be assigned to identify a number of specific facilities, each 
having a bit in the parameter field indicating facility requested/facility not 
requested. In this situation, the parameter field is binary encoded with each bit 
position relating te a specific facility. A "S" indicates that the facility related 
to the particular bit 1s not requested anda ‘'l' indicates that the facility related to 
the particular bit is requested. Parameter bit positions not assigned to a specific 
facility are set to zero. If none of the facilities represented by the facility code 
1s requested for a virtual call the facility code and its associated parameter field 
need not be present. 


A Facility Marker, consisting of a single octet pair, is used to separate requests for 
X.25 facilities, as defined in this section, from requests for non-X.25 facilities 
that may also be offered by an Administration. The first octet is a facility code and 
1s set to zero and the second octet is the facility parameter field. 


The coding of the parameter field will be either all zeros or all ones depending on 
whether the facility requests following the marker refer to facilities offered by the 
calling/source or called/destination network, respectively. For intranetwork virtual 
calls the parameter field should be all zeros. 


Requests for non-X.25 facilities offered by the calling/source and called/destination 
networks may be simultaneously present within the facility field and in such cases two 
Facility Markers will be required with parameter fields coded as described above. 


Within the facility field, requests for X.25 facilities precede all requests for 


non-X.25 facilities and Facility Markers need only be included when requests for 
non-X.25 facilities are present. 
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7.4.2 Coding of Facility Field for Particular Facilities 


7.4.2.1 Coding of Closed User Group Facility 


The coding of the facility code field and the format of the facility parameter field 
for Closed User Group are the same in CALL REQUEST and INCOMING CALL Ctext deleted) 
packets. 
1. Facility Code Field 
The coding of the facility code field for Closed User Groups is: 
bit: 87654321 
code: 00000011 
2. Facility Parameter Field 
The index to the Closed User Group selected for the virtual call is in the form of 
two decimal digits. Each digit is coded in a semi-octet in binary coded decimal 
with bit 5 being the low order bit of the first digit and bit 1 being the low order 
bit of the second digit. 


Indexes to the same Closed User Group at different DTE/DCE interfaces may be 
different. 


7.4.2.2 Coding of Bilateral Closed User Group Facility 


The Bilateral Closed User Group facility is not used in SNA environments. 


(Text deleted). 


7.4.2.3 Coding of Reverse Charging Facility 
The coding of the facility code and parameter. fields for Reverse Charging is the same 
in CALL REQUEST and INCOMING CALL (text deleted) packets. 
1. Facility Code Field 
The coding of the facility code field for Reverse Charging is: 
bit: 87654321 
code: 00000001 
2. Facility Parameter Field 
The coding of the facility parameter field 1s: 
bit 1 = '0° for Reverse Charging not requested 
bit 1 = ti" for Reverse Charging requested 
Note: Bits 6, 5, 4, 3, and 2 may be used for other facilities; if not, they are set to 


*O'. Use of bits 8 and 7 are described in "Coding of Fast Select Facility" on page 
lI-82. 
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7.4.2.4 Coding of RPOA Selection Facility 


The coding of the facility code and parameter fields for RPOA Selection is the same in 
CALL REQUEST and INCOMING CALL Ctext deleted) packets. 


5 Hoe 


2% 


Facility Code Field 

The coding of the facility code field for RPOA Selection is: 
bit: 87654321 
code: 01000100 

Facility Parameter Field 


The cserameter field contains the Data Network Identification Code for the 
requested RPOA transit network, and is.in the form of 4 decimal digits. 


Each digit is coded ina semi-octet in binary coded decimal with bit 5 of the first 
octet being the low order bit of the first digit, bit 1 of the first octet being 
the low order bit of the second digit, bit 5 of the second octet being the low 
order bit of the third digit, and bit 1 of the second octet being the low order bit 
of the fourth digit. 


7.4.2.5 Coding of the Flow Control Parameter Negotiation Facility 


1. 


2 


Coding for Packet Sizes 
The coding of the facility code field and the format of the facility parameter 
field for packet sizes are the same in CALL REQUEST, INCOMING CALL, CALL ACCEPTED 
and CALL CONNECTED packets, where: 
a. Facility Code field 
The coding of the facility code field for packet sizes is: 
bit: 87654321 
code: 010090010 
b. Facility Parameter. Field 
The packet size for the direction of transmission from the called DTE is 
indicated in bits 4, 3, 2, and 1 of the first octet. The packet size for the 
direction of transmission from the calling DTE is indicated in bits 4, 3, 2, 


and 1 of the second octet. Bits 5, 6, 7 and 8 of each octet must be x'"0". 


The four bits indicating each packet size are binary coded and express the 
logarithm base '2' of the number of octets of the maximum packet size. 


Networks may offer values from '4" to '10", corresponding to packet sizes of 
16, 32, 64, 128, 256, 512, or 1024, or a subset of these values. All 
Administrations provide a packet size of '128'". 
Coding for Window Size 
The coding of the facility code field and the format of the facility parameter 
field for window .sizes are the same in CALL REQUEST, INCOMING CALL, CALL ACCEPTED, 
and CALL CONNECTED packets, where: 
a. Facility Code Field 
The coding of the facility code field for window size is: 


bit: 87654321 
code: 01000011 
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b. Facility Parameter Field 
The window size for the direction of transmission from the called DTE is 
indicated in bits 7 to 1 of the first octet. The window size for the direction 
of transmission from the calling DTE is indicated in bits 7 to 1 of the second 
octet. Bit 8 of each octet must be "0'. 


The bits indicating each window size are binary coded and express the size of 
the window. A value of b'0000000" is not allowed. 


Window sizes of °"8' to '127' are only valid if extended sequence numbering is 
used (see "Extended Packet Sequence Numbering™ on page II-69). The ranges of 
values allowed by a network for calls with normal (modulo '8') packet sequence 


numbering and extended (modulo '128') packet sequence numbering are network 
dependent. All Administrations provide a window size of two (2). 


7.4.2.6 Coding of Throughput Class Negotiation Facility 


The coding of the facility code field and the format of the facility parameter field 
for Fhroughput Class Negotiation are the same in CALL REQUEST, INCOMING CALL, CALL 
ACCEPTED AND CALL CONNECTED packets. 
1. Facility Code Field 
The coding of the facility code field for Throughput Class Negotiation is: 
bit: 87654321 
code: 00000010 
2. Facility Parameter Field | 
The throughput class for transmission from the calling DTE is indicated in bits 4, 
3, 2 andi. The throughput class for transmission from the called DTE is indicated 
in bits 8, 7, 6 and 5. 


The four bits indicating each throughput class are binary coded and correspond to 
the throughput classes indicated in Table II-17. 


Table II-17 — Throughput Class Codings 
bits 43 Throughput Class 
bits 8 7 (bit/s) 

Reserved 


Reserved 
Reserved 


Reserved 
Reserved 
Reserved 


mR eS OOOOr KH KH OOOfO 
me OORFM HM OOF KH OOrFF OO | aA 
~mMO-MOrM Or OF OF OFOrF Oo ! UI 


0 
0 
0 
0 
0 
0 
0 
0 
1 
1 
1 
1 
1 
1 
1 
1 
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7.4.2.7 Cading of Fast Select Facility 


1. SNA-to-SNA Connections 


The possible use of the Fast Select facility on SNA-to-SNA CONNECTIONS is a 
subject for further study. 


2. SNA-to-non_SNA Connections 
The coding of the facility code and parameter field for Fast Select is the same in 
CALL REQUEST and INCOMING CALL packets, where: 
a. Facility code field 
The coding of the facility code field for fast select is: 
bit: 87654321 
code: 00000001 
b. Facility parameter field 


The coding of the facility parameter field is: 


bit 8 = 0 and bit 7 = 0 or 1 for fast select not requested 


bit 8 = 1 and bit 7 = 0 for fast select requested with no 
restriction on response 
bit 8 = 1 and bit 7 = 1 for fast select requested with 


restriction on response 


Note: Bits 6, 5, 4, 3 and 2 may be used for other facilities; if not, they are set to 
0. Use of bit 1 is described in "Coding of Reverse Charging Facility” on page II-79. 


7.4.2.8 Coding of Datagram Non-delivery Indication Facility 


The Datagorim Non-delivery Indication facility is not used in SNA environments. 


(Text deleted). 


7.4.2.9 Coding of Datagram Delivery Confirmation Facility 


The Datagram Delivery Confirmation facility is not used in SNA environments. 


(Text deleted). 
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8.0 LOGICAL LINK CONTROL (LLC) ON SNA-TO-SNA CONNECTIONS 


In SNA-to-SNA environments, virtual circuits are viewed, by SNA Physical Unit 
CSNA.PU), SNA Path Control (CSNA.PC) and the higher layers as communication lines 
(physical media) with the ability to support multiple sessions. Permanent virtual 
circuits (PVC)s appear to the higher layers of SNA as dedicated (leased) lines, while 
virtual calls (VCs), also referred to as switched virtual circuits (SVCs), appear as 
switched lines. 


In this environment a logical link control function is required to enhance the quality 
of service provided by the underlying service and to accommodate SNA adjacent node 
physical services equivalent to such SDLC functions as: 


identification information exchange (XID); 
operational mode selection CSNRM, SABM, etc.); 
link test (TEST); and, 

link disconnection (DISC). 


Differences between the error detection and recovery characteristics for adjacent SNA 
nodes in the Public Switched Telephone Network and the Packet-Switched Data Network 
environments are depicted in Figure 19 on page II-84 


Three types of logical link control are defined: 


1. Qualified Logical Link Control (QLLC) which employs the Qualified Data Indicator 
*Q-bit’ in X.25 DATA packets to identify unnumbered and supervisory Receive_Ready 
QLLC commands and responses; and, designed for use with PSDN virtual circuit 
reo ces that exhibit quality of service characteristics that are acceptable to 

e user. 


2. Physical Services Header (PSH) LLC which is employed in certain early IBM SNA X.25 
DTE implementations and described briefly in appendix H; and, 


3. Enhanced Logical Link Control CELLC) which employs extended formats and the 
procedures described in appendix K. ELLC provides error detection and optional 
retransmission recovery capabilities, designed to enhance the quality of service 
exhibited by underlying virtual circuits. While ELLC may be selected by the user 
ona virtual circuit basis, the optional retransmission capability applies to the 
ee er naes and may be controlled by the value of LLC parameter LN2 (see 

-K.6.5.4). 


QLLC and the ELLC procedures described in appendix K are both considered base 
architecture to be supported by all IBM SNA X.25 DTEs except the: 


1. IBM-5973 Network Interface Adapter (NIA) which supports only the PSH protocol; 
and, 


2. IBM-5251-M12 which does not support the ELLC protocol. 


Consequently, IBM SNA X.25 DTEs that remotely attach to the IBM 5973 NIA must be 
capable of using PSH_LLC, as well as QLLC and ELLC. 


The LLC protocol used for operation on PVCs is established by bilateral agreement 
betksen: communicating DTEs, while a Protocol_Identifier (PI) carried in the first 
octet of the Call User Data (CUD) field in X.25 CALL_REQUEST packets is used to 
negotiate the LLC protocol applicable for operation on VCs. CALL_REQUEST packets for 
virtual calls desiring to use ELLC procedures have the PI set to x'C6"'. DTEs that do 
not yet support ELLC, and IBM 5973s that support only PSH_LLC, reject such calls by 
sending a CLEAR _REQUEST packet with the DTE Generated Cause (x'00") and the Diagnostic 
Code #12, ‘Invalid LLC Type’. Calli TEs may then reinitiate the call by sending a 
CALL_REQUEST packet with PI set to/x'C3" requesting a connection for QLLC operation, 
or with PI set to x'C2'" to request a connection for PSH_LLC operation. 


PSH_LLC formats and procedures for their use are outlined briefly in appendix H, while 
the formats, protocols and procedures for ELLC are described in appendix K. 
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Note: PSH_LLC is primary/secondary only. 
ELLC is peer-to-peer only. 


Figure 20. COMMAND/RESPONSE REPERTOIRE: ELLC versus QLLC versus SDLC and 
PSH_LLC 


Peer-to-Peer QLLC, where either link station may initiate actions (i.e., transmit 
commands), utilizes HDLC asynchronous balanced mode (ABM) functions. 


Primary/Secondary QLLC, where only primary link stations initiate actions, utilizes 
HDLC normal response mode (NRM) functions while secondary link stations respond to NRM 
functions tnitiated by primary link stations, and may asynchronously transfer the QRD 
response. 


Procedures for use of the QLLC protocols by Balanced, Primary, and Secondary link 
stations are described in this section. 


8.1 UALIFIED LOGICAL LINK CONTROL (€ QLLC J 


QLLC is designed to facilitate adjacent SNA node physical services where such nodes 
are connected through X.25-based packet-switched data network(s). It uses X.25 DATA 
packets with the Qualifier Bit set equal to '1" ('Q=1"', hereafter referred to as 
"Q@-packets') to transfer HDLC-like commands and responses and 1s to be provided by all. 
Sa 25 DTEs, except the 5973 NIA and the 5251-M12, as a base Logical Link Control 
protoco 


QLLC uses HDLC unnumbered commands and the Receive _Ready supervisory command and 
response, identical to their SDLC counterparts, carried as user data in Q-packets. 
QLLC commands and responses are tinitiated by the same higher level events that 
initiate their SDLC counterparts and timeout processing, as in SDLC, should be 
considered for all QLLC commands. 


8.1.1 Terminology 


QLLC link station configurations include balanced (Cor peer-to-peer) station 
configurations, primary station configurations and secondary station configurations 
that function as described in "Terminology," as well as "combined stations’ that. 
exhibit balanced station characteristics until role negotiation is completed via an 
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exchange of identification information when they assume the role and functions of 


either primary or secondary link stations depending on the outcome of the role 
negotiation process. 


Q@LLC is used by two adjacent link seutiens to exchange elementary units of information 
over a link connection in either of three environments; peer-to-peer, 
primary/secondary or indirectly coupled; as depicted in Figure 21. One link station 
acts as either a PEER or PRIMARY link station, associated with a DTE attached to a PSDN 
via an X.25 DTE/DCE interface to communicate with another link station associated with 
a DTE attached to the same or another PSDN, which acts as either a PEER or SECONDARY. 


In indirectly coupled configurations, a packet assembly/disassembly (PAD) function, 
provided either by the PSDN or as a standalone interface adapter, acts as the "REMOTE 
DTE’ and correlates actions that take place across the link connection to actions that 
take place across the access link connecting the interface adapter and the secondary 


link station. In this environment the secondary link station is referred to as the | 
"Related Secondary Station’ (RSS). 


| PEER-to-PEER 
LOCAL/REMOTE DTE | REMOTE/LOCAL DTE 


PEER PEER 


Link Connection 


Link Station Link Station 


Packet Layer ee Virtual Circuit -—__—_——— Packet Layer 


PRIMARY/SECONDARY 
LOCAL DTE REMOTE DTE 


PRIMARY | SECONDARY 
Link Connection 


Link Station Link Station 


Packet Layer __ OO sd»VVirtual Circuit -— Packet Layer 


INDIRECTLY COUPLED 
LOCAL DTE REMOTE DTE 


| PRIMARY | SECONDARY 
| <-Link Connection -—> | | RELATED 
Link Station Link Stationf<-— Access Link -—>7Secondary 
See ee ee Station 
Packet Layerr<— Virtual Circuit—> Packet Layer 


Figure 21. Qualified Logical Link Control: Environments 


RSS 


8.1.2 Objectives 


The objective of QLLC is to provide adjacent node physical services equivalent to 
those used by SDLC in SNA. It must help to keep the ‘LOCAL DTE* informed of the 
situation in the "REMOTE DTE’ and/or the "Related Secondary Station'. 
Segmentation/concatenation of data packets is performed by the packet level procedures 


at both ends of the link connection by means of the More Data Mark 'M-bit’ procedures 
defined in §-4.3.4. 
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8.1.3 QLLC Elements 


The basic elements of information exchanged are called Logical Link Units (LLUs). Two 
types of LLUs are defined: 


QiLLUS - composed of commands or responses together with their uses and the resultant 
actions performed by link stations at both the local and remote DTEs are described in 
§-8.2 (Elements of Procedure). QLLUs are conveyed between adjacent link stations in 
Q@-packets formatted as shown in Figure 22 on page II-90. 


DLLUS - appeartng as SNA Basic Transmission Units (BTUS), carried in the user data 
field of X.25 DATA packets with the "Q' bit set to zero and the 'M' bit set to either 
*8* or "1", are used to convey user data between adjacent link stations in local and 
remote DTEs. 


The X.25 Delivery Confirmation 'D-bit' procedures are not used. 


8.1.4 Link Connection States 


Link connections may be perceived by link stations as being in any one of six basic 
states at any particular instant in time. 


8.1.4.1 INOPERATIVE 


A link connection is perceived by the link stations to be in the INOPERATIVE state when 
the supporting virtual circuit 1s inoperative. In this state Peer, Primary and 
Secondary link stations neither transmit nor receive QLLUsS or DLLUs. 


8.2.4.2 LINK_CLOSED 


The LINK_CLOSED state is comparable to the LAPB link layer disconnected phase. Peer 
and Primary link stations may initiate an exchange of identification tnformation 
(QXID), or a link test (QTEST) procedure over link connections perceived to be in this 
state. Some may also initiate the link set-up procedure (transmit a QSM command). 
Secondary link stations accept and respond to QxXID and QTEST commands received over 
link connections perceived to be in this state. Some may also accept and respond to 
QSM commands. Some Peer and Secondary link stations respond QDM to @QSM commands 
recetved across link stations in this state until after a successful exchange of 
identification information has been completed. 


8.1.4.3 LINK OPENING 


The LINK_OPENING state is comparable to the link layer set-up phase. Peer and Primary 
link stations expect a response (QUA or QDM) to a set mode (Q5M) command previously 
transmitted across link connections perceived to be in this state. Peer link stations 
also respond (QUA) to set mode (QSM) commands received across link connections 
perceived to be in this state. Secondary link stations accept and respond (QUA) to set 
mode (QSM) commands received across link connections perceived to be in this state. 


8.1.4.4 LINK RECOVERY 


The LINK RECOVERY state is comparable to the link layer frame rejection phase. Peer 
and Secondary link stations retransmit the QFRMR response on link connections 
perceived to be in this state at each respond opportunity until recovery is effected 
by the ‘adjacent link station, or until internal recovery is initiated locally. 
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8.1.4.5 LINK CLOSING 


This state is comparable to the link layer disconnection phase. Peer, Primary and 
Secondary link stations await satisfactory termination of link connections in this 
state. 


8.1.4.6 LINK_OPENED 


The LINK_OPENED state is comparable to the link layer information transfer phase. 
Q@LLUs and DLLUs may be transmitted and received by both link stations across link 
connections perceived to be in this state. 


8.1.5 Link Connection Predicate Conditions 


Predicate conditions applicable to the various states of the link connection include: 


8.1.5.1 Contact Termination Pending - CTp 


Represents the Secondary link station condition in which receipt of a Receive Ready 
CQRR) command QLLU from the Primary link station is required to terminate the 
SNA_CONTACT phase on link connections perceived to be in the LINK_OPENING state. 


8.1.5.2 Other Predicate Conditions - ELSE 


Signifies all predicate conditions not otherwise shown for a particular stimulus. 


8.1.5.3 Incoming/Outgoing TEST Response Pending —- IOTRp 


Transmission and receipt of TEST response QLLUS containing test patterns to and from 
‘the link station tn the adjacent node are pending. 


8.1.5.4 Incoming/Outgoing XID Response Pending - IOXRp 


Transmission and receipt of XID response QLLUS containing link station identification 
information to and from the link station in both adjacent nodes are pending. 


8.1.5.5 Incoming TEST Response Pending - ITRp 


Receipt of a TEST response QLLU containing the test pattern from the link station in 
the adjacent node is pending. 


8.1.5.6 XID/TEST Response Pending - IXOTRp 


Receipt of an XID response QLLU containing link station identification information 
from and transmission of a TEST response QLLU containing the test pattern to the link 
station in the adjacent node are both pending. 
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8.1.5.7 Incoming XID Response Pending - IXRp 


Receipt of an XID response QLLU containing link station identification information 
from the link station in the adjacent node is pending. 


8.1.5.8 No Predicate Condition - NUL 


Sigonifies that no transient predicate condition exists to alter the action required of 
the link station. 


8.1.5.9 TEST/XID Response Pending - OTIXRp 


Receipt of an XID response QLLU containing link station identification information 
from and transmission of a TEST response QLLU containing the test pattern to the link 
station in the adjacent node are both pending. 


8.1.5.10 Outgoing TEST Response Pending - OTRp 


Transmission of a TEST response QLLU containing the test pattern to the link station 
in the adjacent node is pending. 


8.1.5.11 Outgoing XID Response Pending - OXRp 


Transmission of an XID response QLLU containing link station identification 
information to the link station in the adjacent node is pending. 


8.1.5.12 Remote RESTART Pending - RRp 


A RESTART of the X.25 DTE/DCE Interface providing Called (remote) DTE access to the . 
network 1s pending. | 


8.1.5.13 SET_MODE Pending - SMp 


Peer and Primary link stations, having completed ae successful exchange of 
identification information across a link connection perceived to be in the LINK_CLOSED 
state, may transmit a QSM command QLLU when authorized by the higher levels of SNA. 
Peer and Secondary link stations accept and respond to QSM command QLLUsS received on 
link connections perceived to be in this state. 


8.2 QLLC ELEMENTS OF PROCEDURE 


8.2.1 Q-Packet Formats 


SE aca used by QLLC conform to one of the formats depicted in Figure 22 on page 
I-90. 
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| Bits 
8 7 6 5 4 3 2 1 


General format identifier (GFI) 
1 0 0 1 


Octet 
1 Logical channel group number 


| | Logical channel number 
a 
4 | —- - QLL@ Address Field 
(Coded x'FF* for Commands or # x'FF* for Responses) 

5 QLLC Control Field 

6 

e QXID/QTEST/QFRMR Information Field (Optional) 

n 

(Modulo 8) 
Bits 
8 7 6 5 4 3 2 1 
Octet | 
1 pengser format identifier (CGFI) Logical channel group number 
0 1 0 

2 Logical channel number 

a 7 
2 
5 QLLC Address Field | 

(Coded x'FF' for Commands or # x'FF' for Responses) 

6 QLLC Control Field 

3 | 

® 

n 


QXID/QTEST/QFRMR Information Field (COptional) | 


CModulo 128) 
M = More Data Mark 


Figure 22. QUALIFIED_DATA: Packet Formats 


8.2.1.1 QLLC Address Field 


The address field consists of one octet. The contents of the address field is set to 
x'FF" in *Q-packets' containing commands and to any value other than x'FF' in 
"Q-packets? containing responses. | 


8.2.1.2 QULC Control Field 


The control field consists of one octet. The control field contains' the 
command/response transmitted by the peer, primary or secondary link station as 
depicted in Figure 23 on page II-91. 
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8.2.1.3 QLLC Information Field 


The information field consists of a variable number of octets and is used to carry 
QXID, QTEST or QFRMR data. 


8.2.2 QLLC Commands and Responses 


Figure 23 shows the code points for the HDLC commands/responses used by peer, primary 
and secondary QLLC link stations. | 


QLLC C-Field I-Field Primary Secondary Peer-to-Peer 
Function Hex Allowed Command Response 
LOctet 1 


Note: The Address field as defined for SDLC is octet ‘'O*. 


Figure 23. DTE and DCE DATA Packet: User Data Field Format 


8.2.2.1 Q Set Mode - QSM 


The Set_Mode command QLLU is transmitted by peer and primary link stations to place 
the link connection, as perceived by the link station in the adjacent node, in the 
LINK_OPENED state. No information field is permitted with the Q@SM command. 


Upon receipt of the Set_Mode command QLLU peer and secondary QLLC link stations, 
authorized by the higher layers of SNA, transfer a UA response QLLU confirming 
acceptance of the QSM command and place the link connection in the LINK_OPENED state. 
Peer.and primary QLLC link stations, having transferred a Set_Mode command QLLU place 
the Link connection in the LINK_OPENED state upon receipt of the UA response QLLU from 
the peer or secondary QLLC link station in the adjacent node. 


8.2.2.2 Q Disconnect - QDISC 


The Disconnect command QLLU is transferred by peer and primary Q@LLC link stations to 
place the link connection, as perceived by the peer or secondary QLLC link station in 
the adjacent node, in the LINK_CLOSED state. No information field is permitted with 
the Q@DISC command. | 


Upon receipt of the DISC command QLLU peer and secondary QLLC link stations, on link 
connections perceived to be in other than the LINK_CLOSED state, transfer a UA 
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response QLLU confirming acceptance of the QDISC command and place the link connection 
in the LINK_CLOSED state. Link connections perceived to be in the LINK_CLOSING state, 
by peer and primary Q@LLC link stations, are placed in the LINK_CLOSED state upon 
receipt of a UA response QLLU by that QLLC link station. 


8.2.2.3 Q_Exchange_Identification - QxID 


The Exchange_Identification command QLLU may be issued by peer and primary QLLC link 
stations at any time to solicit identification information from the peer or secondary 
communicating link station in the adjacent node. The information field of the QXID 
command/response contains the transmitting link station's identification information. 


Upon receipt of an XID command QLLU, peer and secondary QLLC link stations transfer 
the corresponding XID response QLLU as soon as the identification information is 
available. 


8.2.2.4 Q Test_Link - QTEST 


The TEST command QLLU may be issued by peer and primary QLLC link stations at any time 
to solicit a TEST response QLLU from the peer or secondary QLLC link station in the 
adjacent node. The information field of the TEST command/response contains the test 
pattern data. 


Upon receipt of a TEST command QLLU, peer and secondary QLLC link stations transfer 
the corresponding TEST response QLLU with the information field contatning the test 
pattern data received in the QTEST command. 


8.2.2.5 Q Request Disconnect - QRD 


The Request_Disconnect response QLLU may be used by secondary QLLC link stations to 
request the primary QLLC link station to place the link connection as perceived by the 
secondary QLLC link station in the LINK_CLOSED state (Ci.e., initiate the link 
disconnection procedure by transferring a QDISC command across the link connection). 
As a result of receiving a DISCONTACT or similar request from a higher SNA level, 
secondary QLLC link stations may transfer a Q@RD response,» when. no other responses 
(such as acknowledgments for received DLLUS or responses to received Unnumbered 
commands) are pending and start Query Timer, Tq. Should Query Timer Tq expire prior to 
receipt of the requested QDISC command, the QRD response may be retransmitted up to Nq 
times. DLLUs received by the secondary QLLC link station after transmission of the 
Q@RD response and prior to receipt of the requested QDISC command are accepted and 
responded to in the normal way. No information field is permitted with the QRD 
response. 


Upon receipt of a @QRD response the primary QLLC link station will transfer a QDISC 
command when authorized by a higher levels of SNA. 


8.2.2.6 Q_Unnumbered_Acknowledgment —- QUA 


The Unnumbered_Acknowledgment response QLLU is transferred by peer and secondary QLLC 
link stations in response to Q@SM or QDISC commands. No information field is permitted 
with the QUA response. 


Upon receipt of the QUA response across a link connection perceived by a peer or 
primary @QLLC link station to be itn the LINK_OPENING state the receiving peer or 
primary QLLC link station places that link connection in the LINK_OPENED state. Upon 
receipt of the QUA response across a link connection. perceived by a peer or primary 
Q@LLC link station to be in the LINK_CLOSING state the receiving peer or primary QLLC 
link station places that link connection in the LINK_CLOSED state. 
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8.2.2.7 Q Receive Ready - QRR 


The Recéive_ Ready command QLLU may be transferred by peer and primary QLLC link 
stations to indicate that the link connection is in the LINK_OPENED state and the QLLC 
Link stations are prepared to accept and respond to DLLUs. 


8.2.2.8 @_Disconnected_Mode - QDM 


The Disconnected_Mode response QLLU may be transferred by peer and secondary QLLC link 
stations in response to Q@SM or QDISC commands. No information field is permitted with 
the QDM response. 


Receipt of a Q@DM response informs the receiving peer or primary QLLC link station that 
the link connection, as perceived by the communicating QLLC link station in the 
adjacent node, is in the LINK_CLOSED state. 


8.2.2.9 Q Frame_Reject - QFRMR 


The Frame_Reject response QLLU may be used by peer and secondary QLLC link stations to 
inform the communicating QLLC link station in the adjacent node of an error condition 
that is considered to be unrecoverable, at the LLC level, by retransmission of the 
identical LLU. 


Upon receipt of a QFRMR response, peer and primary QLLC link stations cause a clearing 
of the VC or a resetting of the PVC supporting the link connection and inform a higher 
SNA level protocol of the failure. The format of the information field of the 
Frame_Reject response QLLU is depicted in Figure 24. 


I-field bits 
2 7 8 


Rejected LPDU 
Control Field 


® Rejected LPDU control field is the control field of the received 
LPDU that caused the frame reject. 


° V¥Vs is reserved and set to b'000"'. 
e Vr is reserved and set equal to b*000". 
® 'W=1" indicates that the control field received and returned in bits 


1 through 8 was considered invalid or not implemented. 

° "X=1' indicates that the control field received and returned in bits 
1 through 8 was considered invalid because the LPDU contained an 
information field which is not permitted or is an S or U-frame with 
incorrect length. "W=1" in required in conjunction with this bit. 

® "Y=1'" indicates that the information field received exceeded the 
maximum established capacity of the link station reporting the rejection 
condition. 

® ‘Z" is reserved and set equal to b'0°. 

Note: Bit 13 is set to: 


"1' If the LPDU rejected was a response; or, 
"9" If the LPDU rejected was a command. 
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5 Figure 2¢. QFRMR: Information Field Format 


The format of the CUD field for CALL_REQUEST and INCOMING CALL packets on SNA~to-SNA 
connections is illustrated in Figure 25. 


Bits 8 7 6 5 4 3 2 1 


8.2.3 Call User Data ( CUD ) Field Format 
Octet 
0 
2 
2 
? 
2 


COptional ) 
1 Field Format Identifier (FFI) 


2 ELLC Call Control Indicator 
2 2 x x x x x x x I/R 
2 

3 ‘ 

e | Format Specific Field | | 

15 

I/R = 'O0' for initial connection. 
= "1" for connection recovery. 
Note: Bits indicated as 'x’ are reserved and should be set to 0's 


—_ eee LOIN IN ND 


Figure 25. CALL_USER_DATA Field Format: CALL_REQUEST and INCOMING CALL Packets 


8.2.3.1 Field_Format_Identifier ( FFI ) 


The FFI is optional and when present, defines the format of the remainder of the CUD 
field. IBM SNA X.25 DTE implementations that use FFIs must make such use optional. 
IBM SNA X.25 DTEs that do not support FFIs must accept and ignore CUD fields of up to 
15 octets in addition to the Protocol Identifier. Figure 26 on page JI-95 illustrates 
the format of the CUD field for the only optional FFI currently defined, b'xxxxxxxl]' 
where the bits denoted by 'x's, bits 8 thru 2, are reserved and set to zeroes. 


mesmmnese f\} 
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Bits 8 7 6 5 q 3 2 1 
Octet 
0 


1 Field _Format_Identifier 
x x x x 


2 ELLC_Call_Control_Indicator 
x x x 


3 Reserved 


8 | Connection_Identi fier : | 


0" for initial connection. 


"1" for connection recovery. 
Note: Bits indicated as 'x' are reserved and should be set to 0's 


Figure 26. CALL_USER_DATA Field Format: CALL_REQUEST and INCOMING CALL Packets 
with Connection_Identifiers. 


8.2.3.2 ELLC_Call_Control_Indicator - ( ELLC_CCI ) 


The ELLC_CCI (bit 1 of octet 2) is used to distinguish between initial connection 
requests and connection recovery requests, while the remaining bits, denoted by ‘x's 
in Figure 25 on page II-94% and Figure 26, are reserved and set to zero ('0's). 


8.2.3.3 Connection_Identifier - ( CI ) 


The CI is eight octets in length and permits IBM SNA X.25 DTEs to accept or reject 
incoming calls based on its content. The following rules apply to the use of the 
optional CI: 


1. Some IBM SNA X.25 DTEs may not support the Connection_Identifier. 


2. For IBM SNA X.25 DTEs that do support a Connection_Identifier, its use is optional 
ona per call basis at the discretion of the user. 


3. IBM SNA X.25 DTEs that support Connection_Identifiers may reject incoming calls by 
transferring a CLEAR_REQUEST with the Diagnostic Code #236 (Connection Identifier 
Mismatch) when the Connection_Identifier does not compare with one that is 
expected. 


8.3 DESCRIPTION OF THE QLLC PROCEDURES 


Charts in "Balanced Link Stations” on page II-104, "Primary Link Stations" on page 
II-116 and "Secondary Link Stations" on page II-123 specify actions taken by balanced 
(PEER), primary and secondary QLLC link stations, respectively, as a result of events 
that occur, and LLC command and response LLUS received on link connection perceived to 
be in the various states. 
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8.3.1 Link Set-Up 


8.3.1.1 Initiation - Al 


Peer and primary QLLC link stations authorized by the higher levels of SNA, initiate 
link setup by transferring a Set_Mode command QLLU placing the link connection in the 
LINK_OPENING state. Some may also start LLC Query Timer (Tq). 


8.3.1.2 Acknowledgment - A2 


Upon receipt of a Set _ Mode command QLLU, peer and secondary QLLC link stations 
authorized by the higher levels of SNA to enter the LINK_OPENED state transfer the 
corresponding UA response QLLU. Secondary QLLC link stations then place the link 
connection in the LINK_OPENED state. 


Alternatively, some secondary QLLC link stations may set the link connection predicate 
condition to contact termination pending (CTp) and await receipt of a Receive_Ready 
CRR) command QLLU before placing the link connection in the LINK_OPENED state. Peer 
QLLC link stations maintain the link connection in the LINK_OPENING state until a UA 
response QLLU is received from the QLLC link station in the adjacent node. 


8.3.1.3 Initiation_Retry - A3 


Should Query Timer (Tq) expire prior to receipt of the UA response QLLU or a DM 
response QLLU to the transmitted Set_Mode command or a CLEAR/RESET, indicating that 
the peer or secondary QLLC link station in the adjacent node 1s not operational, peer 
and a gel link stations may retransmit the Set_Mode command QLLU and restart Query 
Timer (Tq). 


8.3.1.4 Failure - A& 


After Nq retransmissions of the Set_Mode command QLLU, peer and primary QLLC link 
stations place the link connection in the INOPERATIVE state and report the condition 
to the higher levels of SNA. 


8.3.1.5 Waiting - AS 


Peer and primary QLLC link stations, that do not implement Query Timer, Tq, may wait 
for a UA response QLLU to the transmitted Set_Mode command, or a packet level reset, 
indicating remote DTE operational, on the virtual circuit supporting the link 
connection before taking any further action. 


8.3.1.6 Completion - A6 


Upon receipt of the UA response QLLU to a transmitted Set _Mode command QLLU, peer and 
primary QLLc link stations stop Query Timer, Tq, if it is running, place the link 
connection in the LINK_OPENED state and report the status of the link connection to 
the higher levels of SNA. Some peer and primary QLLC link stations may also transmit a 
link Recetve_ Ready (RR) command QLLU. 
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8.3.1.7 Alternative - A7 


Alternatively, peer and primary QLLC link stations may transfer a Set_Mode command 
QLLU following receipt of a packet level RESET, indicating remote DTE operational, on 
the virtual circuit supporting the link connection. Some may also start Query Timer, 
Tq. 


8.3.1.8 Rejection - A8 


Peer and secondary QLLC link stations not authorized, by the higher levels of SNA, to 
set-up the link respond to received Set_Mode command QLLUs by transferring a DM 
response QLLU and maintain the link connection in the LINK_CLOSED state. 


8.3.2 User Data Transfer 


8.3.2.1 Data_Transfer - Bl 


Peer, primary and secondary QLLC link stations on link connections perceived to be in 
the LINK_OPENED state cooperate in the exchange of X.25 DATA packets with "Q=0" in 
' accordance with the procedures described in §-4.3. 


8.3.2.2 Resetting - B2 


QLLC link stations receiving a Set_Mode command QLLU or a DM response QLLU on a link 
connection perceived to be in the LINK_OPENED state cause a clearing of the VC or a 
resetting of the PVC supporting the link connection and report the status and reason 
for the change of status in the link connection to the higher levels of SNA. 


8.3.3 Link Disconnection 


8.3.3.1 Primary_Initiation - Cl 


During the LINK_OPENED state Cinformation transfer phase), peer and primary QLLC link 
stations indicate link disconnection, as dictated by the higher levels of SNA, by 
transferring a Disconnect command QLLU across the link connection. Some may also 
start Query Timer, Tq. 


8.3.3.2 Secondary_Initiation - C2 


Secondary QLLC link stations indicate link disconnection, as dictated by the higher 
levels of SNA, by transferring a Request_Disconnect response QLLU, across the link 
connection. Some may also start QLLC Query Timer, Tq. 


8.3.3.3 Acknowledgment - C3 


Upon receipt of a DISC command QLLU, receiving peer and secondary QLLC link stations 
return a UA response QLLU, place the link connection in the LINK_CLOSED state and 
report the status of the link connection to the higher levels of SNA. 
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8.3.3.4 Primary_Response - C4 


Upon receipt of an RD response QLLU, primary QLLC link stations inform the higher 
levels of SNA and transfer a DISC command QLLU across the link connection. Some may 
also start Query Timer, Tq. 


8.3.3.5 Collision - C5 


In the event of a collision of unlike QLLC commands, peer QLLC link stations transfer a 
DM response QLLU at the earliest opportunity, placing the link connection in the 
LINK_CLOSED state and report the status of the link connection to the higher levels of 


e 


8.3.4 Link Disconnected Phase 


8.3.4.1 Reporting - Dl 


Peer and secondary QLLC link stations, having received a DISC command QLLU and 
returned a UA response QLLU; and, peer and primary QLLC link stations having received 
a QUA response to a transmitted DISC command QLLU, place the link connection in the 


LINK_CLOSED state and report the status of the link connection to the higher levels of 
SNA. - 


8.3.4.2 Activation - D2 


Peer and primary QLLC link stations on link connections perceived to be in the 
LINK_CLOSED state may initiate the link set-up procedure as described in §-8.3.1 when 
authorized by the higher levels of SNA. 


8.3.4.3 Connecting - D3 


Peer and secondary QLLC link stations on link connections in the LINK_CLOSED state 
that are authorized by the higher levels of SNA react to the receipt of Set_Mode 
command QLLUs as described in §-8.3.1. 


8.3.4.4 Response - D¢ 


Peer and secondary QLLC link stations on link connections in the LINK_CLOSED state 
transfer a DM response Q@LLU upon receipt of DISC command QLLUs. 


8.3.5 Link Identification Exchange 


8.3.5.1 Initiate_ID_Exchange - El — 


ox 
Sy 


Peer and primary QLLC link stations may initiate the exchange of link identification 
information, in certain states, by transferring an XID command QLLU and starting Query 
Timer, Tq. | x. 


a 


6 wee 
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8.3.5.2 Complete_ID_ Exchange - E2 


Upon receipt of an XID command QLLU, peer and secondary QLLC link stations transfer an 
XID response QLLU when authorized by the higher levels of SNA. 


8.3.6 Link Test 


8.3.6.1 Initiate_Link_Test - Fl 


Peer and primary QLLC link stations may initiate the link test procedure, in certain 
states, by transferring a TEST command QLLU and starting Query Timer, Tq. 


8.3.6.2 Complete_Link_Test - F2 


Upon receipt of a TEST command QLLU, peer and secondary QLLC link stations transfer a 
TEST response QLLU as soon as authorized by the higher levels of SNA. 


8.3.7 External Effects on Logical Link Control Procedures 


Certain states and actions are dictated by SNA layers above or below QLLC and are as 
described as follows. 


8.3.7.1 L3_Ready_Signal - Gl 


@LLC link stations become operational when the Packet Layer (level 3) interface 
signals the READY state. 


8.3.7.2 Set-Up_Link - G2 


QLLC link stations perform the link setup only when authorized by the higher levels of 
SRA . 


8.3.7.3 Disconnect_Link - G3 


Q@iLC link stations initiate the link disconnection procedure when authorized by the 
higher levels of SNA. | 


8.3.7.4 L3_Inoperative_Signal - G4 


QLLC link stations become inoperative and inform the higher levels of SNA when the 
Packet Layer (level 3) interface signals the inoperative state. 


8.3.7.5 XID_Function_Request - G5 —- Obsolete 


QLLC link stations initiate an exchange of link station identification information at 
the LLC level only at the request of the higher levels of SNA. 
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8.3.7.6 TEST_Function_Request - G6 —- Obsolete 


QLLC link stations initiate a procedure to test the link when authorized by the higher 
levels of SNA. 


8.3.7.7 Exchange_Identification - G7 


QLLC link stations transfer link station identification information command or 
response QLLUs as appropriate when authorized by the higher levels of SNA. 


8.3.7.8 TEST_Link Connection - G8 


Q@LLC link stations transfer link test command or response QLLUs as appropriate when 
authorized by the higher levels of SNA. 


8.3.7.9 DATA_Transfer - G9 


QLLC link stations cooperate with the higher levels of SNA.to exchange BTUs over link 
connections perceived to be in the LINK_OPENED state. 


8.4 STATE/ACTION CHART DESCRIPTION 


Operation of the QLLC protocol for balanced, primary and secondary link stations is 
formalized by the charts contained in "State/Action Charts” on page IJI-104. Action(s) 
taken by link station(€s) as a result of particular stimuli are shown at the 
intersection of the various link connection states and the stimulus. LLC stimuli 
include the events and command and response LLUs defined in §-8.4.1. QLLC link 
connection states include the predicate conditions defined in §-8.1.5 which are 
indicated under the heading 'P:' Cif any) in the state/action charts. 


Information contained at these intersections specify the action(s) taken, (denoted by 
two uppercase letters 'LL* or by a single uppercase letter concatenated with a number 
*"L#¥'), the LLUCs) to be transferred Cif any), enclosed in brackets with any required 
parameters [LLU, parms] and the new state of the link connection to be entered Cif 
any). 


The LLUCs) to be transferred, [CLLUJ], may be any of the LLC command or response LLUs 
depicted in Figure 23 on page II-91. In the event the LLU to be transferred causes a 
packet level clearing or resetting of the associated virtual circuit, an appropriate 
diagnostic code must be included (see Appendix F for DTE Generated Diagnostic codes 
used on SNA-to-SNA connections). When no LLU to be transferred, [LLU], is indicated, 
nothing 1s transferred across the link connection. 


Applicable QLLC link connection state transitions are specified under the heading New 
State when the link connection is to be placed in a new state following the specified 
action and/or transfer of the LLU specified by [LLU]. Link connections remain in the 
current state when no new state to be entered is specified. 


Alternative procedures, denoted by lower case letters "ll" or ‘or' under the CALT) 
heading, are specified where appropriate. 


References to clarifying notes (denoted by ‘fn’ (where 'n' is a decimal digit) under 
the CALT) heading) is also provided at certain intersections, where deemed necessary, 
to explain extenuating circumstances considered essential to proper operation of the 
protocol, including: 


1. An exchange of QLLC link station identification information is not eoanee prior 
to link set-up. 
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2. The virtual call (switched virtual circuit) supporting the link connection is 
cleared (e.g., CLEAR_REQUEST or CLEAR_INDICATION) the underlying virtual circuit 
1s terminated and the QLLC link connection placed in the INOPERATIVE state. 


3. Combined QLLC link stations assume the characteristics of either a primary or 
secondary QLLC link station upon completion of XID role negotiation. 


Sample sequences derived from the QLLC State/Action charts are shown in Figure 27 
on page II-134 as an example of how the tables may used. 


8.4.1 QLLC Stimuli 


QLLC protocol stimuli include the events, commands and responses described in the 
following paragraphs. 


8.4.1.1 Events 


L3RDY - Packet Layer (level 3) Ready: Represents a signal from the X.25 Packet Layer 
Clevel 3) that the underlying virtual circuit is in the READY (p4 or dl) state. 


LSTRT - Link_Start: Represents higher level stimulus to initiate the LLC Set-Up 
procedure for the link connection. 


LSTOP - Link_Stop: Represents higher level stimulus to initiate the LLC disconnection 
procedure for the link connection. 


L3NOP - Level _3_Inoperative: Represents a signal from the Packet Layer (level 3) that 
the underlying virtual circuit is INOPERATIVE. 


ERRPK - Erroneous_Packet: Represents receipt of an erroneous packet (e.g., a Q-packet 
containing an unidentifiable command/response, etc.) on the link connection. 


XCHID - Exchange_Identification: Represents a higher level request for or 
authorization to transfer link identification information. 


LTEST - Link_Test: Represents a higher level request for or authorization to transfer 
link test data. 


SDATA - SEND Data: Represents a higher level request for the transfer of unqualified 
user data to the packet layer (level 3) procedures. 


CLRST - Virtual Circuit CLEAR/RESET: Represents a packet level clearing of the 
virtual call, or resetting of the virtual circuit, supporting the link connection. 


LLTOX - Link_Timeout_Expiration: Represents expiration of link reply timeout, Timer 
Tq. 


8.4.1.2 Commands Sent or Received 
UDP - Unqualified _Data_Packet: Represents a DATA packet with the Qualifier "Q" bit 
equal to zero. | 


Q@SM - Q Set_ Mode: Represents a Q Packet containing a Set_Mode command QLLU (QS5M) in 
the user data field. 


@pc - Q Disconnect (QDISC): Represents a Q Packet containing a Disconnect command 
QLLU CQDISC) in the the user data field. | 


QxcC - Q Exchange Identification (QXID): Represents a Q Packet containing an 
Exchange_Identification command (QXID) in the user data field. 


QTC - Q Logical Link_Test (QTEST): Represents a Q Packet containing a Test command 
QLLU CQTEST) in the user data field. 
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QRR - Q_P’::@ive-Ready: Represents a Q Packet containing a Receive _Ready command QLLU 
CQRR) in the user data field. | 


8.4.1.3 Responses Serit and Received 


QDM - Q Disconnected_Mode: Represents a Q Packet containing a Disconnected_Mode 


response QLLU (QDM) in the user data field. 


QFR - Q Frame_Reject (QFRMR): Represents a @Q Packet containing a Frame_Reject 
response QLLU (QFRMR) in the user data field. 


QRD - Q Request_Disconnect: Represents a Q Packet containing a Request_Disconnect 
response QLLU (QRD) in the user data field. 


QUA = Q@ Unnumbered_Acknonledge: Represents a Q Packet containing an 
Unnumbered_Acknowledge response QLLU (QUA) in the user data field. 


RXR - @Q Exchange_Identification (QXID): Represents a Q@ Packet containing an 
Exchange_Identification response QLLU (QXID}, including link station identification 
information, in the user data field. 


QTR - Q_Test (QTEST): Represents a Q Packet containing a Link_Test response QLLU 
CQTEST), including test data, in the user data field. 


QRR - Q Receive-Ready: Represents a Q Packet containing a Receive_Ready response QLLU 
(QRR) in the user data field. 


C/R - CLEAR or RESET packet: Represents a clearing of the virtual call or a resetting 
of the permanent virtual circuit supporting the link connection by 
transmisston/receipt of a CLEAR _REQUEST/CLEAR_INDICATION or 
RESET_REQUEST/RESET_INDICATION packet, respectively. 


8.4.2 Actions 


Actions taken by QLLC link stations, noted at the intersection of a 
state/condition/option and a stimulus, include those identified by a capital letter 
concatenated with a number 'L#' (which refer to the procedures specified in §-8.3) and 
those identified by two capital letters 'LL' defined as follows: 


8.4.2.1 IC - Increment Retransmission Count 


Increment the (Cre)-transmission count and, if the retry limit has not been exceeded, 
retry the protocol procedure. Otherwise, report the failing procedure to, and await 
further direction from, the higher levels of SNA. 


8.4.2.2 IH - Inform Higher Layers 


Inform the higher layer(s) of SNA via internal signalling mechanisms. 


8.4.2.3 IP - Ignore Packet 


Ignore the received packet. 


8.4.2.4 IT - Initiate Query Timer, Tq 
Initiate a logical link timeout for the duration of Query Timer, Tq. 
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8.4.2.5 LE - Local Procedure Error 


Representing an internal signalling error or illogical protocol sequence on the part 
of the QLLC link station that may be either ignored or reported to a higher layer of 
SNA for future analysis. 


8.4.2.6 NA - Not Applicable 


Identifies events/actions/responses that cannot occur for a given 
stece/conditicn/alternative. 


8.4.2.7 NS - No Specific Action 


No specific action is required by the QLLC link station protocol. 


8.4.2.8 RE - Remote Procedure Error 


Representing a protocol procedure error on the part of the Q@LLC link station in the 
adjacent node that may be either ignored or reported to a higher layer of SNA for 
future analysis. 


8.4.2.9 RS - Report Status 


Report the current status of the QLLC link station to a higher level of SNA. 


8.4.2.10 TC - Terminate Contact 


Terminate the SNA_CONTACT phase and signal CONTACTED to a higher level of SNA. 


8.4.2.11 TT - Terminate Timer Tq 


Terminate the LLC Query Timer, Tq. 
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8.5 STATE/ACTION CHARTS 
8.5.1 Balanced Link Stations 


8.5.1.1 Balanced INOPERATIVE State 


CHART B1-E: EVENTS in INOPERATIVE State 


Stimuli P: CALT)| Action(s) [LLU Transfers] | New State 


L3RDY G1, P=NUL LINK_CLOSED 


(Shp 
XCHID | 
LTEST 


LE 
LE 
LE 
LE 
LE 
a 


LLTOX 


CHART Bi-I: DLLUs in INOPERATIVE State 


Stimuli P: CALT)]|. Action(s) [LLU Transfers] New State 


CHART B1-S: S-format QLLUs in INOPERATIVE State | 


Stimuli P: CALT)I Action(s) [LLU Transfers] New State 
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CHART B1-U: U-format QLLUs in INOPERATIVE State 


Stimuli P: CALT)I Action(s) [LLU Transfers] 


L 


m 


QDCc 


= = Se er 
m mpm) mee 


LE 
QxCc 
QXR LE 
QTC LE 


mm 
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8.5.1.2 Balanced LINK_CLOSED State 


CHART B2—-E: EVENTS in LINK_CLOSED State 


Stimult P: CALT)I Action(s) | (LLU Transfers] New State 


LSTRT NUL #1 Al, P=NUL LINK_OPENING 


SMp Al, P=NUL LINK_OPENING 


XCHID NUL 
OXRp 
IOXRp 
OTRp 
SMp 
ELSE 
NUL 
GXRp 
OTRp 
IOTRp 
IXOTRp 


LLTOX RY 
ELSE RS, P=NUL 


CHART B2-I: DLLUS in LINK_CLOSED State 


Stimuli P: CALT)] Action(s) | {LLU Transfers] New State 
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CHART B2-S: S-format QLLUs in LINK_CLOSED State 


Stimuli P: CALT)]| Action(s) [LLU Transfers] New State 


CHART B2-U: U-format QLLUs in LINK_CLOSED State 


Stimuli P: CALT)| Action(s) PLU Transfers] 


QSM NUL 


A2, P=NUL LINK_OPENED 
LINK_OPENING 
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CHART B2-U: U-format Q@LLUs in LINK_CLOSED State 


NUL 
IXRp 
IOXRp 
IXOTRp 
ELSE 


NUL 
ITRp 
OTRp 
IOTRp 
ITOXRp 
ELSE 
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8.5.1.3 Balanced LINK_OPENING State 


CHART B3-E: EVENTS in LINK_OPENING State 


Stimuli P: CALT)] Action(s) [LLU Transfers] New State 


RS, P=NUL 


RS, P=NUL 


LINK_CLOSED 
LINK_CLOSED 


LINK_RECOVERY 
LINK_CLOSED 
LINK_RECOVERY 
LINK_CLOSED 


LINK_CLOSED 


LINK_CLOSED 


LINK_CLOSED 


A6, P=NUL 


NNUNMVUNNMNNNUNNNNMNUNNMNNNNNNNNNNNNNNNNMNUNNNNNNNNNNNNNNNNVNNNNNNNANNNNNNNNNANN 
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CHART B3-I: DLLUs in LINK_OPENING State 


Stimuli P: CALT)]}] Acticn(s) [LLU Transfers] New State 
IP 


CHART B3-S: S—format QLLUs in LINK_OPENING State 


Stimuli P: CALT)| Action(s) [LLU Transfers] New State 


CHART B3-U: U-format QLLUs in LINK_OPENING State 


Stimuli P: CALT)] Action(s) (LLU Transfers] New State 


Q 
OXRp 
OTRp 


SM 
adc 


LINK_CLOSED 
LINK_CLOSED 
LINK_CLOSED 


RRp 


LINK_CLOSED 
LINK_CLOSED 
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8.5.1.4 Balanced LINK_CLOSING State 


CHART B4&-E: EVENTS in LINK_CLOSING State 
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CHART B4-I: DLLUs in LINK_CLOSING State 


Stimuli P: CALT)] ActionCs) [LLU Transfers] 


CHART B4-S: S-format QLLUs in LINK_CLOSING State 
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CHART B4-U: U-format QLLUs in LINK_CLOSING State 
Stimuli P: (CALT)| Action(s) [LLU Transfers] | New State 
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8.5.1.5 Balanced LINK RECOVERY State 


CHART B5-E: EVENTS in LINK_RECOVERY State | 


Stimuli P: CALT)| Action(s) | ———sdELLU Transfers] | New State 
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CHART B5-I: DLLUs in LINK_RECOVERY State 


Stimuli P: CALT)} Action(s) [LLU Transfers] New State 
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CHART B5-S: S-format QLLUsS in LINK_RECOVERY State 


Stimuli P: (CALT)}| Action(s) [LLU Transfers] New State 
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CHART B5—-U: U-format QLLUs in LINK_RECOVERY State 
Stimuli P: CALT) 
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8.5.1.6 Balanced LINK_OPENED State 


CHART B6-E: EVENTS in LINK_OPENED State 


}ustop ss | 3 [apc]| LINK_CLOSING 
G4 | INOPERATIVE 


XCHID NUL 


OXRp 
OTRp 
ITOXRp 
ELSE 


NUL 
OXRp 
OTRp 
IXOTRp 
ELSE 


SDATA 
P#NUL 
or 


CHART B6-I: DLLUs tn LINK_OPENED State 
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CHART B6-U: U-format QLLUs in LINK_OPENED State 
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6.5.2 Primary Link Stations 


8.5.2.1 Primary INOPERATIVE State 


CHART P1-I: DLLUs in INOPERATIVE State 


Stimuli P: CALT)| Action(s) [LLU Transfers] New State 
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CHART P1—-U: U-format QLLUs in INOPERATIVE State | 


Stimuli P: CALT)]}] Action(s) [LLU Transfers] New State 
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8.5.2.2 Primary LINK_CLOSED State 


' CHART P2-E: EVENTS in LINK_CLOSED State 


Stimuli P: CALT)] Action(s) [LLU Transfers] New State 
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CHART P2-I: DLLUs in LINK_CLOSED State 


Stimuli P: CALT)| Action(s) [LLU Transfers] 
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CHART P2-S: S—-format QLLUs in LINK_CLOSED State 


Stimuli P: CALT)| Action(s) [LLU Transfers] 


CHART P2-U: U-format QLLUs tn LINK_CLOSED State 
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8.5.2.3 Primary LINK_OPENING State 


CHART P3-E: EVENTS in LINK_OPENING State 
Stimuli P: CALT) 
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CHART P3-I: DLLUS in LINK _ OPENING State 
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CHART P3-U: U-format QLLUs itn LINK_OPENING State 
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8.5.2.4 Primary LINK_CLOSING State 


CHART P4—-E: EVENTS in LINK_CLOSING State 
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CHART P4-I: DLLUs in LINK_CLOSING State 


Stimuli P: CALT)| Action(s) [LLU Transfers] New State 
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CHART P4-U: U-format QLLUs in LINK_CLOSING State 


Stimuli P: CALT)] Action(s) [LLU Transfers] New State 
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8.5.2.5 Primary LINK_RECOVERY State 


LINK_RECOVERY state is Not Applicable to Primary QLLC link stations. 


8.5.2.6 Primary LINK_OPENED State 


CHART P6-E: EVENTS in LINK_OPENED State 
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CHART P6-I: DLLUs in LINK_OPENED State 


Stimuli P: CALT)| Action(s) [LLU Transfers] New State 
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CHART P6-S: S-format QLLUs in LINK_OPENED State 


Stimuli P: CALT)] Action(s) [LLU Transfers] New State 


CHART P6—-U: U-format QLLUs tin LINK_OPENED State : 
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8.5.3 Secondary Link Stations 


§.5.3.1 Secondary INOPERATIVE State 


CHART S1-E: EVENTS tn INOPERATIVE State 
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CHART S1-I: DLLUs in INOPERATIVE State 
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CHART S1-U: U-format QLLUs in INOPERATIVE State 
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8.5.3.2 Secondary LINK_CLOSED State 


CHART S2-E: EVENTS in LINK_CLOSED State 
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CHART S2-I: DLLUs in LINK_CLOSED State 
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CHART S2-S: S-format QLLUs in LINK_CLOSED State 
Stimuli P: 
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CHART S2-U: U-format Q@LLUs in LINK_CLOSED State 


Stimuli P: CALT)] ActionCs) [LLU Transfers] | New State 
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8.5.3.3 Secondary LINK_OPENING State 


CHART S3-E: EVENTS in LINK_OPENING State 
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CHART S3-I: DLLUs in LINK_OPENING State 
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CHART S3-U: U-format QLLUs in LINK_OPENING State 


Stimuli P: CALT)1 Action(s) [LLU Transfers] New State 
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8.5.3.4 Secondary LINK_CLOSING State 
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CHART S4-I: DLLUs in LINK_CLOSING State 


Stimuli P: CALT)| Action(s) [LLU Transfers] New State 
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CHART S4-S: S—format @LLUs in LINK CLOSING State : 
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8.5.3.5 S<condary LINK_RECOVERY State 


CHART S5-E: 
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CHART S5-I: DLLUs in LINK_RECOVERY State 


Stimult P: CALT)]{ Action(s) CLLU Transfers] New State 


CHART S5-S: S-—format QLLUs in LINK_RECOVERY State 
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8.5.3.6 Secondary LINK_OPENED State 
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CHART S6-I: DLLUs in LINK _OPENED State 


Stimuli P: CALT)] Action(s) CLLU Transfers] New State 
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CHART S6-S: S-format QLLUsS in LINK_OPENED State 
Stimuli P: 
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8.6 SAMPLE QLLC SEQUENCES 


QLLC 


sequences for "typical”™ error free peer-to-peer, link activation, 


initialization, data transfer, disconnection and deactivation derived-from the charts 


in 


"Balanced Link Stations™ on page II-104 and depicted in Figure 27 on page II-134% 


zre described as follows. 


1. 


QLLC link stations, upon recognition of a transition of the supporting logical 


channel (virtual call or permanent virtual circuit) to the READY state (L3RDY 
event), become operative (G1), signal adapter enabled (CEABLD) to the upper 
layer(s) of SNA and place the underlying link connection in the LINK_CLOSED state. 


An SNA_CONTACT results in the upper layer(s) of SNA requesting an exchange of link 
station identification information (XIDFR) causing the QLLC link station to 
initiate an exchange of link station identification information (G65) by 
transferring an Exchange_Identification command QLLU (QXC) and set P=IXRp 
Cincoming link station identification information pending). 


QLLC link stations, upon receipt of the QXID command [QXC] in the LINK_CLOSED 
state inform a higher leyer of SNA CIH), passing the link station identification 
information contained in the information field of the received QLLU (DATA), sets 
P=OXRp Coutgoing Link identification information pending) and may start Query 
Timer Tq. - 


Q@LLC link stations in adjacent nodes with P=OXRp (Coutgoing identification 
information pending), when authorized by the upper layer(s) of SNA CXRSPR), 
respond to the received QXID command (G7) by transferring a QXID response [QXR] 
containing their link station identification information in the information 
field, set P=SMp Clink set mode pending) and stop the Query Timer, Tq, if it is 
running. 


QLLC link stations with P=IXRp Cincoming link identification information 
pending), upon receipt of the QXID response [QXR] inform the upper layer(s) of SNA 
CIH) passing the identification information contained in the information field of 
the received QLLU (DATA) and set P=SMp Clink set mode pending). 


When authorized by the upper layer(s) of SNA (LSTRT) QLLC link stations with P=SMp 
Clink set mode pending) initiate the link setup procedure (Al) by transferring a 
Set_Mode command QLLU, set P=NUL, place the underlying link connection in the 
LINK_OPENING state and may initiate a timeout for the duration of Query Timer, Tq. 


Upon receipt of the Set _Mode command QLLU (QSM), QLLC link stations with P=SMp 
Clink set mode pending), respond to the received Q@SM command (CA2) by transferring 
an Unnumbered_Acknowledge response QLLU [QUA], set P=CTp and place the link 
connection in the LINK_OPENING state. 


Upon receipt of the QUA response, QLLC link stations on connections perceived to 
be in the LINK_OPENING state with P=SMp Clink set mode pending), tnform the upper 
layer(s) of SNA CIH) by signalling CONTACTED, transfer a Receive_Ready command 
QLLU CQRR) informing the communicating link station in the adjacent node to 
terminate the CONTACT phase, set P=NUL, place the link connection in the 
LINK_OPENED state and stop the Query Timer, Tq, if it 1s running. 


Upon receipt of a QRR command, QLLC link stations in adjacent nodes on connections 
perceived to be in the LINK_OPENING state with P=CTp, inform the higher layer(s) 
of SNA (IH), set P=NUL and place the link connection in the LINK_OPENED state. 


Q@LLC link stations on connections in the LINK_OPENED state with P=NUL exchange 
C[DLLUJ]s on behalf of the upper layer(s) of SNA as requested (DTRFRC(DATA)) via the 
logical channel (virtual call or permanent virtual circuit) supporting the link 
ge and respond to QLLUs and internal stimuli as previously specified in 
=6:.'0 


An SNA DISCONTACT results in the upper layer(s) of SNA requesting a link 
termination (CLSTOP) causing Q@LLC link stations to initiate a link disconnection 
procedure (G3) by transferring a Disconnect command QLLU [QDC] placing the link 
connection in the LINK_CLOSED state. 


Upon recetpt of a QDISC command (Q@DC), QLLC link stations on connections perceived 
to be in the LINK_OPENED state with P=NUL, inform the higher layers of SNA (IH) by 
signalling INOP_LNK, respond to the received QDISC command (C3) by transferring a 
QUA response and place the underlying link connection in the LINK_CLOSED state. 
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“pon receipt of a QUA response on a link connection perceived to be in the 
LINK _CLOSING state, QLLC link stations on connections with P=NUL, inform the 
higher layer €s) of SNA (CIH) by signalling +RSP and place the underlying link 
connection in the LINK_CLOSED state. 

6. Uron receipt of a signal from the Packet Layer (Level 3) that the supporting 
logical channel Cvirtual call or permanent virtual circuit) is in the INOPERATIVE 
state (CL3NOP) QLLC link stations place the associated link connection in the 
INOPERATIVE state and report this status (RS) to the higher layer(€s) of SNA by 
signalling adapter disabled (DABLD). 

In Figure 27 on page II-134: 
a. Time progresses from top to bottom of the figure. 


b. The various layers at the origin and destination DTEs are represented by 
vertical lines. 


c. QLLC link station states are represented by their abbreviated names in the 
_ vertical line representing the logical link control (LLC) layer. 


d. Signal and data flows are represented by horizontal lines with arrowheads 
denoting the direction of flow. : 


e. External stimuli are represented by labels above the origin end of the flow 
lines and numbers enclosed in brackets [#] as described above. 


f. QLLC actions and state transitions are shown above the origin end of the flow 
lines and the resulting command/response/signal transferred is shown below 
the arrowhead denoting direction of flow; and, 

e DABLD - represents an Adapter Disabled Signal. 
e EABLD - represents an Adapter Enabled Signal. 
e ULSNA - represents the Upper Layer(s) of SNA. 


e X25PL - represents the Packet Layer of X.25. 
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ORIGINATION DESTINATION 
| LOGICAL LINK STATIONS | 
ULSNA LLC X25PL X25PL LLC ULSNA 
| PSDN(s) | 
NOPTV P 


C1]J— SIGNAL LOGICAL SIGNAL 
G1_b°® [< CHANNEL'S 
(2]— 
(3]— 
[4]— 
DATAIN 
(5]— VARYOFF 
CLSNG 
IH_b® ;< 
< 
CLOSD 
[6]— SIGNAL CLEAR/RESET|] SIGNAL 


RS_a® f< 
< 


DABLD 


Figure 27. QLLC_Flows: Exchange ID, Link Set-Up, Data Transfer and Link 
Disconnection 
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9.0 OTHER SYSTEM CONSIDERATIONS 
9.1 SECURITY 


9.1.1 SNA-to-SNA Connections 


Called DTEs can implement a rudimentary calling DTE identification check by testing 
the calling DTE address in INCOMING CALL packets. DTEs can elect to implement as a 
user option the connection identifier capability defined for CALL REQUEST and INCOMING 
CALL packets. 


Care must be exercised in choosing cryptographic techniques. Data link control level 
cryptographic products defined for SNA procucts are not defined for the X.25 link and 
packet levels and cannot be used. Cryptographic products defined for SNA above, and 
transparent to, the data link control level can be used. 


9.1.2 SNA-to-non SNA Connections 


Security techniques are specific to the particular non-SNA remote DTE being supported. 
In general, techniques used for SNA-to-SNA connections are not applicable. 


9.2 RELIABILITY, AVAILABILITY AND SERVICEABILITY (RAS) 


RAS characteristics of PSDNs are not clearly established. However, numerous error 
detection and reporting mechanisms”~ are included throughout this interface 
specification to aid in problem determination. 


9.2.1 Philosophy 


The fundamental philosophy adopted for error reporting in PSDN environments is one of 
commonality. IBM SNA X.25 DTEs cover a broad spectrum of RAS capabilities. 
Therefore, reporting to a higher level may mean different things for different 
products. These can range from simply reporting an error condition to the local 
operator of a simple DTE to full compatibility with Network Problem Determination and 
Analysis programs. 


A common set of Diagnostic Codes is specified in Appendix F for use by all IBM SNA X.25 
DIES in reporting error conditions and abnormal situations to higher levels of SNA. 


9.2.2 Summary of Error Conditions 


Detectable error conditions are divided into four general categories: 


1. those resulting from receipt of unsupported packet types (i.e., DCE INTERRUPT or 
DCE DATAGRAM packets). 


2. those that can result from a discrepancy between the DTE and DCE interpretations 
of the state of some subscribed interface parameter. (i.e., receipt of an 
INCOMING CALL packet on a logical channel assigned for permanent virtual circuit 
service); and 


3. those most likely resulting from a malfunction of the DCE Ci.e., receipt of an 
unsolicited DCE RESTART CONFIRMATION packet); 


&. those caused by failures at the physical level or the link level. (Ci.e., dropping 
of the Data Set Ready indication). 
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IBM SNA X.25 DTEs, upon detection of errors in category: 


"1" or '2' - clear the virtual call or reset the permanent virtual circuit if such 
an action is permitted without violating any procedure. The error condition is 
reported to a higher level of SNA; the received packet is discarded. 


"3" - transmit a RESTART REQUEST packet across the DTE/DCE interface, place all 


virtual circuits in an tnoperative state and report the error condition to the 
higher levels of SNA. 


"4" - place the LAPB link and all virtual circuits at the DTE/DCE interface in an 
inoperative state and report an interface failure to a higher level of SNA. 


9.2.3 General Recommended Actions 


Errors detected at the X.25 DTE/DCE interface, either by IBM SNA X.25 DTEs or their 
associated DCEs, that result in CLEAR, RESET or RESTART indications must be reported 
to the SNA control point or to the local operator, as appropriate. The Call Progress 
Signals (CPS) defined in CCITT Recommendation X.96 used for "Network Generated’ Cause 
and Diagnostic Codes defined in CCITT Recommendation X.25 and a common set of 'DTE 
Originated’ diagnostic codes defined in Appendix F for IBM SNA X.25 DTEs to aid in 
problem determination are used for reporting purposes. Session outage notifications 
are propagated in accordance with general SNA mechanisms, using INOPERATIVE CINOP) to 
the control point and RECORD FORMATTED MAINTENANCE STATISTICS CRECFMS) or RECORD 
MAINTENANCE STATISTICS CRECMS) to Communication Network Management 
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A.0 APPENDIX A: ASSIGNMENT OF LOGICAL CHANNELS 


ates of logical channels used for virtual calls and permanent virtual circuits (text 
eleted). 


A.1 LOGICAL CHANNEL ASSIGNMENT 


Logical channel number one (x'001") is used by DTEs that support a single logical 
channel. 


A range of logical channels must be agreed upon with network Adminjstrations for 
multiple logical channel DTE/DCE interfaces, according to Figure A-1. 


L_c_lI 


Reserved 


Permanent Virtual Circuits (Text deleted) 


One-Way 
Incoming 


Virtual Calls 


; | Two-way 
HTC (Switched Virtual Circuits) 
LOC 

Z One-Way 

‘ Outgoing 
HOC 


. : Non—Assigned 
4095 


Figure A-~-1l. Assignment: Logical Channels 


With reference to Figure A-l1: 


0 is a logical channel reserved exclusively for the transmission of RESTART and 
DIAGNOSTIC packets. 


1 to LIC-1 is the range of logical channels assigned for permanent virtual 
circuits. 


LIC to HIC is the range of logical channels assigned to one-way incoming logical 
channels for virtual calls (see §-7.1.8). 


LTC to HTC is the range of logical channels assigned to two-way logical channels 
for virtual calls. 


LOC to HOC is the range of logical channels assigned to one-way outgoing logical 
channels for virtual calls (see §-7.1.7). 


HIC+1 to LTC-1, HTC+1 to LOC-1, and HOC+t1 to 4095 are unassigned logical channels. 


Note: 


: 


Logical channels are numbered according to a set of contiguous numbers ranging 
from 0 Clowest) to 4095 Chighest) using 12 bits made up of a four (4) bit Logical 
Channel Group Number (see §-6.1.2). and an eight (8) bit Logical Channel Number 
(see §-6.1.3). Logical channel numbers are binary coded in bit positions four (4) 
through one (1) of octet one (1) followed by bit positions eight (8) through one 
C1) of octet two (2) with bit one (1) of octet (2) betng the low order bit. 
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2. All logical channel boundaries are agreed upon with the network Administration for 
a period of time. 


3. To avoid frequent rearrangement of logical channels, not all logical channels 
within the range allocated for permanent virtual circuits are necessarily 
assigned. | 


4. In the absence of permanent. virtual circuits, logical channel number one is 
available for LIC. In the absence of permanent virtual circuits and one-way 
incoming logical channels, logical channel one is available for LTC. In the 
absence of permanent virtual circuits, one-way incoming logical channels and 
two-way logical channels, logical channel one is available for LOC. 


5. DCEs use the lowest numbered logical channel in the READY state in the range LIC to 
HIC and LTC to HTC as the logical channel for new incoming calls. 


6. To minimize the risk of call collision, DTEs use the highest numbered logical 


channel in the READY state for outgoing calls. DTES may use either two-way 
logical channels or one-way outgoing logical channels. 
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B.0 APPENDIX B: PACKET LEVEL STATE DIAGRAMS 
Packet level DTE/DCE interface state diagrams 


B.l SYMBOL DEFINITION OF THE STATE DIAGRAM 


Transition | 


DTE 
Bee Responsibility for the transition 


Vv 


State name 


PACKET TYPE } Packet transmitted 


> 
 Jransition 


Note: 
| 1. States are represented by boxes wherein the state name and number are indicated. 


2. State transitions are represented by arrows. The station (DTE or DCE) responsible 
| for the transition and the packets transferred is indicated inside the arrow. 


B.2 ORDER DEFINITION OF THE STATE DIAGRAMS 


The normal procedure at the DTE/DCE interface is described in a number of small state 
diagrams. To describe the normal procedure fully it is necessary to allocate a 
priority to the different figures and to relate a higher order diagram with a lower 
one. This is done by the following means: 


e The figures are arranged in order of priority with Figure B-1 (Restart) having the 
highest priority and subsequent figures having lower priority. Priority means 
that when a packet belonging to a higher order diagram is transferred, that 
diagram is applicable and the lower order one is not. 


° The relation with a state in a lower order diagram is given by including that state 
inside a box in the higher order diagram. 
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PACKET LEVEL READY 


READY 
pl or dl 
(Note 1) 


DTE DCE 


RESTART A A RESTART 
REQUEST INDICATION 
DCE DTE 
RESTART RESTART 
CONFIRMATION CONFIRMATION 
or or 
RESTART RESTART 

INDICATION REQUEST ) 


r2 


DTE RESTART 
REQUEST 


DCE DTE r3 


DCE RESTART 
INDICATION 


DTE 


RESTART RESTART 
REQUEST INDICATION 
(Note 3) (Note. 2) 


Note: 


1. State pil is for virtual calls and state dl is for permanent virtual 


circuits. 
2. This transition may take place after time-out T10. 
3. This transition may take place after a 200 second time-out. 


Figure B-1l. States for the Transfer of RESTART packets 
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iT 32. 


CALL 
CONNECTED 


DTE 


CALL 
REQUEST 


DCE 


DCE A 


INCOMING 
CALL 


p5 


CALL 
COLLISION 


DCE 


CALL 
CONNECTED 
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DCE 


INCOMING 
CALL 


DCE WAITING 


DTE 


CALL 
REQUEST 


di 
FLOW CONTROL READY 


pP4 
DATA TRANSFER 


Note: This transition may take place after a 200 second time-out. 


Figure B-2. 
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States for the Transfer of Call Set-Up Packets within the 


PACKET LEVEL READY (rl) §$ 


PACKET LEVEL STATE DIAGRAMS 


tate 


DTE 


CALL 
ACCEPTED 


LI=58=3 


SNA/X.25 DTE/DCE Interface 


ANY STATE 


except 


_ 


p6 or p7 
CLEAR CLEAR 
REQUEST — INDICATION 
DCE V DTE DCE V_ DTE CALL 
ACCEPTED 
p CLEAR ee 2) 


CALL. | Pe SS = REQUEST CLEAR 
CONNECTED DTE CLEAR (Note 5) INDICATION DCE CLEAR 


| or 
(Note 1) REQUEST (Note 3) INDICATION CALL 
REQUEST 
A DCE A A DTE A (Note 4) 


DCE DTE 
CLEAR CONFIRMATION CLEAR CONFIRMATION 
or or 7 
CLEAR REQUEST 


DCE 
CLEAR INDICATION 


Notes: 


1. This transition is possible only if the previous state was DTE 
WAITING (p2). 


2. This transition is possible only if the previous state was DCE 
WAITING Cp3). 


3. This transition may take place after Time-out T13. 


4. This transition is possible only if the previous state was READY (pl) 
or DCE WAITING (p3). 


5. This transition may take place after a 200 second time-out. 


Figure B-3. States for the Transfer of Call Clearing Packets within the 
PACKET LEVEL READY (rl) State 
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DTE DCE 


RESET RESET 
INDICATION REQUEST 
RESET or | or RESET 
REQUEST DCE DTE INDICATION 
RESET RESET 


CONFIRMATION CONFIRMATION 


DCE DTE 


DTE DTE RESET < > DCE RESET DCE 
REQUEST INDICATION 

RESET RESET 
REQUEST . INDICATION 


(Note 2) CNote 1) 


Note: 


1. This transition may take place after time-out T12. 


2. This transition may take place after a 200 second time-out. 


Figure B-4. States for the Transfer of RESET Packets within the 
DATA TRANSFER (Cp4) State. 
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C.0 APPENDIX C: DCE PACKET LEVEL ACTIONS 


Actions taken by the DCE on receipt of packets ina given state of the packet level 
DTE/DCE interface as perceived by the DCE. 


C.1 DCE STATE/ACTION TABLES 


TABLE C_1: Special Cases 


Numbers following a & are diagnostic codes in decimal notation. 
(See Appendix E) 


Packet from the DTE Any State 


Any packet with packet length less than 2 octets DIAG #38 
Any packet with incorrect General Format Identifier (GFI) DIAG #40 


Any packet other than RESTART_REQUEST or CONFIRMATION on DIAG 
unassigned logical channel or LCI = x'000' #36 


Any packet with correct GFI and See Table 
assigned logical channel C_2 


DIAG: DCEs discard the received packet and, on networks that implement 
diagnostic packets, transmit a#$DIAGNOSTIC packet containing the indicated 
diagnostic code to the DTE. 


There may be more than one error associated with a packet. Networks stop normal 
processing of packets when an error is encountered. Thus, only one diagnostic code 
is indicated in DIAGHOSTIC packets. The order of packet de-coding and checking is 
not standardized among networks. 
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Table C_2: DCE actions on Receipt of packets in a given state of the 
| packet level DTE/DCE interface as perceived by the DCE: 
Restart Procedure for assigned logical channels 


The figures in-parentheses () are the new states to be entered. 
Figures following a # are diagnostic codes in decimal notation. 
(Note 1). 


State of the 
interface as PACKET DTE DCE 
perceived by LEVEL | RESTART RESTART 
Packet from the DCE READY REQUEST INDICATION 
the DTE with rl r2 r3 
assigned logical 
channel 


RESTART REQUEST NORMAL DISCARD NORMAL 
(r2) Cr2) (pl ur dl) 
Note 2 


DTE RESTART CONFIRMATION ERROR ERROR NORMAL 
Cr3) Cr3) Cpl or dl) 
#17 #18 Note 2 


DATA, CLINTERRUPT], CALL SET-UP and See ERROR DISCARD 
CLEARING, FLOW CONTROL Table Cr3) (r3) 
or RESET C_3 #18 


RESTART REQUEST OR DTE RESTART See ERROR DISCARD 
CONFIRMATION WITH BITS 1 to 4 of Table (r3) (r3) 
OCTET 1 or BITS I to 8 of OCTET 2 C_3 #41 

NOT EQUAL TO ZERO. 


PACKETS HAVING A PACKET TYPE See ERROR DISCARD 
IDENTIFIER WHICH IS SHORTER THAN 1 Table Cr3) Cr3) 
OCTET OR IS NOT SUPPORTED BY THE DCE C_3 #38 #33 


NORMAL: DCEs follow the procedures defined in §-3. When RESTART_REQUEST packets 
or DTE_RESTART_CONFIRMATION packets received in state r3 exceed the maximum 
permitted length, DCEs invoke the ERROR procedure with diagnostic #39 and enter 
state r3. When RESTART_REQUEST packets received in state rl exceed the maximum 
permitted length, the action taken by DCEs is for further study. 


DISCARD: DCEs discard the received packet and take no subsequent action as a direct 
result of receiving that packet. 


ERROR: DCEs discard the received packet and indicate a restarting by transmitting 
a RESTART_INDICATION packet, with the cause, "Local Procedure Error” (diagnostic per 
Table €_2)}. On virtual calls, the remote DTE is informed of the restarting by a 
CLEAR_INDICATION packet, with the cause "Remote Procedure Error™ (same diagnostic). 
On permanent virtual circuits, the remote DTE is informed by a RESET_INDICATION 
packet, with the cause "Remote Procedure Error” (same diagnostic). 


When a RESTART_INDICATION is issued as a result of an error condition in state r2, 
DCEs eventually consider the DTE/DCE interface to be in the PACKET LEVEL READY state 
Cri). Eventually consider is interpreted to mean after sixty (60) seconds. 

Note: 


1. There may be more than one error associated with a packet. Networks stop normal 


processing of packets when an error 18S encountered. Thus, only one diagnostic 
code is associated with an error indication by DCEs. The order of packet 


de-coding and checking on networks is not standardized. 


2. State pl for logical channels assigned to virtual calls; or, dl for logical 


channels assigned to permanent virtual circuits. 
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TABLE C_3: Actions by DCEs on Receipt of Packets in a given State of 


the Packet Level DTE/DCE Interface as Perceived by the DCE: 
Call Setup and Clearing on Assigned Logical Channels. 


The letters and numbers in (ln) are the new states to be entered. 
Numbers following a # are diagnostic codes in decimal notation (Note 1). 


PACKET LEVEL READY rl 


Interface 
States as 


perceived DATA CALL {DTE CLEAR|DCE CLEAR 
by the DCE TRANSFER|COLLISON} REQUEST |INDICATION 
eran p4 p5 p6 p7 


Packet on 
assigned 
LCI 


Note 2,3 


CRQ ERROR NORMAL ERROR ERROR DISCARD 
(p7) (p5) Cp7) (p7) (p7) 
#21 Note 4 #24 #25 

CAC ERROR 
(p7) 


#21 


ERROR ERROR DISCARD 
Cp7) Cp7) Cp7) 
#24 #25 


NORMAL] NORMAL| NORMAL NORMAL NORMAL DISCARD NORMAL 
(p6) C(p6) (p6) (p6) (p6) (p6) | (pl) 
Note: 5 


(p7) (p7) (p7) 
#20 #21 #22 


= | 
TCC ERROR ERROR ERROR ERROR ERROR NORMAL 
(p7) (p7) (pl) 
#24 #25 


DIR|FC ERROR ERROR ERROR ERROR ERROR DISCARD 
Cp7) (p7) (p7) C(p7) (p7) (p7) 
#20 #21 #22 #24 #25 
IRR|TIR ERROR ERROR ERROR ERROR DISCARD 
(p7) 


w/LCI#0 (p7) Cp7) (p7) (p7) 
#41 #41 #41 C_4 #41 


See DISCARD 
Table Cp7) 
C_4 


CRQ: CALL_REQUEST 

CAC: CALL_ACCEPTED 

CLR: CLEAR_REQUEST 

TCC: DTE_CLEAR_CONFIRMATION 
DIR|FC: DATA, CINTERRUPT,] RESET or FLOW_CONTROL 
IRR[TIR: RESTART_REQUEST or DTE_RESTART_CONFIRMATION 


UNK|NUP: Packets having a Packet Type Identifier shorter than one octet or that 
are not supoorted by the DCE. 


ee LCI: Logical Channel Identifier (bits 1-4 of octet #1 plus bits 1-8 of octet 


NORMAL: DCEs follow the procedures defined in §-4. For packets exceeding the 


maximum permitted length, DCEs invoke the ERROR procedure with diagnostic #39 and 
enter state p/7. . 
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DISCARD: DCEs discard the received packet and take no subsequent action as a direct 
result of receiving that packet. 


ERROR: DCEs discard the received packet and indicate a clearing by transmitting a 
CLEAR INDICATION packet, with the cause "Local Procedure Error” (diagnostic per Table 

. € 3). On virtual calls, the remote DTE is informed ‘of the clearing by a 

CLEAR_-INDICATION packet, with the cause "Remote Procedure Error" (same diagnostic). 


It is required that itn the absence of. an appropriate DTE response to a 
CLEAR_INDICATION packet issued as a result of an error condition in state p6, the DCE 
should eventually consider the DTE/DCE interface to be in the READY state (pl). 
Eventually consider is interpreted to mean after sixty (60) seconds. 


Note: 


1. There may be more than one error associated with a packet (e.g., packet too long 
and transmitted in a wrong state). Networks stop processing of packets when an 
error its encountered. Thus, only one diagnostic code is associated with an ERROR 
indication by DCEs. The order of packet de-coding and checking is not 
standardized among networks. 


2. This state does not exist for one-way logical channels outgoing (as perceived by 


DTEs). 

3. pee ageen ce does not exist for one-way logical channels incoming (as perceived by 

DTEs). 

4. 

a. For one-way logical channels incoming (Cas perceived by DTEs) DCEs transmit a 
CLEAR_INDICATION packet with the cause "Local Procedure Error” and diagnostic 
code #34. 

b. DCEs transmit a CLEAR INDICATION packet when a CALL REQUEST packet contains an 
improper address format or facility field; call progress signals and 
diagnostic codes are listed below: 

ERROR CONDITION CAUSE DIAG 
1. Address contains a non BCD digit LPE 67,68 
2. Prefix digit not supported LPE 67,68 
3. National address smaller than 

national address format permits LPE 67,68 
4. National address larger than 
national address format permits LPE 67,68 
5. DNIC less than four digits LPE 67,68 
6. Facility length larger than 63 LPE 64 
7. No combination of facilities 
could equal facility length LPE 64 
8. Facility length larger than _ 
remainder of packet LPE 38 
9. Facility values conflict Ce.g., 
a particular combination not 
supported) LPE 66 
10. Facility code not allowed IFR 65. 
ll. Facility value not allowed IFR 66 
LPE = Local procedure error 
IFR = Invalid facility request 
DNIC = Data Network Identification Code 

c. DCEs transmit a CLEAR_INDICATION packet when a remote DTE makes a procedure 
error, either for one of the above reasons associated with its call 
acceptance, or because of an expired timeout (diagnostic #49). 

5. For permanent virtual circuits, DCEs discard the received packet and indicate a 


reset by transmitting a RESET_INDICATION packet, with the cause "Local procedure 
error™ (diagnostic #35). The remote DTE is informed of the reset by a 


APPENDIX C: DCE PACKET LEVEL ACTIONS | iT=C=% 


SNA/X.25 DTE/DCE Interface 


RESET_INDICATION packet, with the cause "Remote Procedure Error™ (same 


diagnostic). 


Text deleted. 


6. The ERROR procedure is’ invoked by DCEs when CALL_ACCEPTED packets contain an 
improper address format or facility field. Examples are similar to those in Note 


G4 point (b) above. 


7. #=The presence of the Fast Select facility, indicating restriction on response in an 


INCOMING CALL packet prohibits the DTE from sending a CALL_ACCEPTED packet. 


TABLE C_4: Actions taken by the DCE on Receipt of Packets in a given 
State of the Packet Level DTE/DCE Interface as Perceived 
by the DCE: Data Tranz:fer (Flow Control and Reset) on 
Assigned Logical Channels 


The figures tn parentheses () are the new states to be entered; the 
figure following a # 1s the diagnostic code in decimal notation 
(Note 1). 


State ‘of the interface DATA TRANSFER p4 


as perceived by 
Packet from the DCE FLOW CONTROL DTE RESET DCE RESET 
the DTE with READY REQUEST INDICATION 
assigned logical channel d2 


di d3 
RESET REQUEST NORMAL DISCARD NORMAL 
(d2) Cd2) (dl) 
DTE RESET CONFIRMATION ERROR ERROR NORMAL 
Cd3) #27 (d3) #28 ~ Cdl) 
DATA, CINTERRUPT] OR NORMAL ERROR DISCARD 
Cd3) #28 (d3) 


FLOW CONTROL (d1l} 
Note 2 
ERROR ERROR DISCARD 
(d3) Cd3) (d3) 
#41 #41 
ERROR ERROR DISCARD 
(d3) Cd3) (d3) 
THAN ONE OCTET OR IS NOT #27 #28 
SUPPORTED BY THE DCE 


INVALID PACKET TYPE ON A ERROR ERROR DISCARD 

PERMANENT VIRTUAL CIRCUIT Cd3) #35 Cd3) #35 (d3) 

REJECT PACKET NOT SUBSCRIBED ERROR ERROR DISCARD 
Cd3) #37 Cd3) #37 (d3) 


NORMAL: DCEs follow the procedures defined in §-4. For packets exceeding the 
maximum permitted length, DCEs invoke the error procedure using diagnostic code #39 
and enter state d3. 


RESTART REQUEST OR DTE RESTART 
CONFIRMATION WITH BITS 1 to 4 
OF OCTET 1 OR BITS 1 to 8 OF 
OCTET 2 # 0 


PACKETS HAVING A PACKET TYPE 
IDENTIFIER WHICH IS SHORTER 


DISCARD: DCEs discard the received packet and take no subsequent action as a direct 
result of receiving that packet. 


ERROR: DCEs discard the received packet and indicate a reset by transmitting a 
RESET_INDICATION packet, with the cause "Local Procedure Error” (diagnostic per 
Table C-4). On virtual calls and permanent virtual circuits the remote DTE is 
informed of the reset by a RESET_INDICATION packet with the cause "Remote Procedure 
Error™ (same diagnostic). 


When a RESET_INDICATION is issued as a result of an error condition in state d2 for 
permanent virtual circuits, (text deleted) DCEs should eventually consider the 
DITE/DCE interface to be in the FLOW CONTROL READY state (dl). The action to be taken 
on virtual calls is for further study. 


Note: 
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1. 


There may be more than one error associated with a packet (e.9., Invalid Ps and 
Invalid Pr). Networks stop processing of packets when an error is encountered. 


Thus, only one diagnostic code is associated with an error indication by DCEs. 


The order of packet de-coding and checking is not standardized among networks. 


DCEs consider the receipt of a DTE_INTERRUPT_CONFIRMATION packet which does not 
correspond to a yet unconfirmed DCE_INTERRUPT packet as an error and resets the 


virtual call or permanent virtual circuit (diagnostic #43). DCEs either discard 


or consider as an error a DTE_INTERRUPT packet received before a previous 
DTE_INTERRUPT packet has been confirmed (diagnostic #44). 


When Ps or Pr received is not valid, DCEs invoke the error procedure with 
diagnostics #1 and #2, respectively, and enter state d3 
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. APPENDIX D: TIME-LIMITS AND TIME-OUTS 


Packet level DCE time-outs and DTE time-limits. 


D.1 


DCE TIME-OUTS 


In 


certain circumstances DTEs are required to respond to packets issued from DCEs 


within a stated maximum time. 


Table II-D-1 covers these circumstances and the actions that DCEs initiate upon 
expiration of that maximum time. 


| To 


facilitate recovery from such fault conditions, IBM SNA X.25 DTEs incorporate 


timers. Time-out values are indicated for DTE implementations in Table II-D-2. 


| Text deleted. 


ON 
fom | 


TABLE II-D-1: DCE TIME-OUTS 


Time—Out 


Actions taken when the time-out 
ae (see Note 1) 
Local Side Side Remote Side 


DCE remains in r3 |For PVCs, DCE 
and may send a DGNienters state d3 
packet. (Note 2) signalling RSI 
(remote proce— 
dure error) 


Normally 
Beate Starts Terminated 


when 


DCE sends 
IRI pkt 


Value 


r3 DCE leaves 


TSC or IRR 
is rec'd) 


180 
secs. 


3 {DCE sends 


an INC 


DCE enters state 
p?7 signalling a 

CLI Clocal proce- 
dure error) 


DCE enters state 
p7 signalling a 

CLI Cremote proce- 
dure error) 


T12 d3 |DCE sends 


an RSI 


For VCs, DCE en- 
liters state p/7 

signalling CLI 

Clocal procedure 
error). For PVCs, 
DCE remains in d3 
and may send a DGN 
pkt (Note 3) 


For PVCs, DCE en- 
ters state p/ 
signalling CLI 
Cremote procedure 
error). For PVCs, 
DCE enters state 
d3 signalling RSI 
Cremote procedure 
error) 


secs. 


is rec'd) 


T13 60 p7 |DCE sends{[DCE leaves DCE remains itn p7 
secs. a CLI state p/7 and may send a DGN 
secs. Ce.g., the packet. (Note 4) 

TSC or CRQ 


1s rec'd). 


Notes with reference to Table II-D-1: 


Lig: ; 


The following Notes 2, 3 and 4 describe alternative DCE actions on timer 
expiration. It is envisaged that all networks will eventually conform to Table 
II-D-1, however, for an interim period the following procedures may be used. 


No values have yet been assigned to the time-out t and the maximum number. of 
retries n applying to the following notes, however, it should be noted that some 
Administrations may use the combination t-infinite, n-zero Ci.e., no retries and 
no recovery action) or t-finite, n-zero (Ci.e., no retries with recovery action on 
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timer expiration). The values of n and t will not necessarily be the same for the 
clear, reset and restart procedures. 


Alternatively, DCEs may retransmit a RESTART INDICATION packet at regular 
intervals of '‘'t! aye a DTE RESTART CONFIRMATION is received or a restart 
collision occurs or a riod ('ntl")'t" elapses since the first transmission of 
the RESTART INDICATION. If the restart procedure is not completed within the 
time-out period, appropriate recovery action is taken. 


Alternatively, DCEs may transmit a RESET INDICATION packet at regular intervals of 
*t" until a DTE RESET CONFIRMATION is received or a reset collision occurs or a 
pertod ('ntl1')'t' elapses since the first transmission of the RESET INDICATION. 
If the reset procedure is not completed within the time-out period DCEs either: 


a. clear the virtual call with a procedure error indication; or, 


b. reset the permanent virtual circuit by transmitting a RESET INDICATION packet 
(remote procedure error) to the local DTE at regular intervals ‘'t' until a DTE 
RESET CONFIRMATION is received or a reset collision occurs. 


Alternatively, DCEs may retransmit a CLEAR INDICATION at regular intervals of 't! 
until a DTE CLEAR CONFIRMATION is received or a clear collision occurs or a period 
C'nti'd't' elapses since the first retransmission of the CLEAR INDICATION. If the 
clear procedure is not completed within the time-out period, appropriate recovery 


-action is initiated. The nature of the recovery action is for further study. 
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D.2 DTE TIME-OUTS AND TIME-LIMITS 


In certain circumstances DCEs are required to respond to packets from DTEs within a 
stated maximum time. The actual DCE response times’ should be well within the 
specified time-limits. The rare situation where a time-limit is exceeded should only 
occur when there is a fault condition. 


To facilitate recovery from such fault conditions, IBM SNA X.25 DTEs incorporate 
timers. Time-out values for IBM SNA X.25 DTE implementations are indicated in Table 
Ti-D=2: 


| Text deleted. 


TABLE II-D-2: DTE TIME-OUTS and DCE TIME-LIMITS (see NOTE) 


Pimes ares 
re Starts 
180 DTE sends 
secs. 


an IRR 
T21 


T22 180 
 |Secs. 


Request pkts may be re- 
transmitted at 200 sec. 
intervals '"n20' times 
after an initial time- 
out. Following which, 


Terminates 
Normally 
when 


DTE leaves state r2 
Ci.e., the NSC or IRI 
rec'd) 


the interface becomes 
inoperative and restart 
failure notification is 
given to a higher 

level. 


DTE sends 
a CRQ 


DTE leaves 
Ce.g., the CCN, CLI or 
INC pkt is rec'd) 


the logical channel be- 
comes inoperative and 
call failure notifica- 
tion is given to a 
higher level. 


DTE sends 
an RSR 


DTE leaves state d2 
Ce.g., the NRC or RSI is 
rec'd) 


the logical channel be- 
comes inoperative and 
reset failure notifica- 
tion is given to a 
higher level. 


¥23 180 p6 DTE sends 
secs. a CLR 


DTE leaves state p6 
Ce.g., the NCC or CLI is 
rec'd) 
is received) 


the logical channel be- 
comes inoperative and 
clear failure notitfica- 
tion is given to a 
higher level. 


Note: DTE time-outs are 200 seconds. 
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E.0 APPENDIX E: DCE DIAGNOSTICS 


Coding of xX.25 network generated diagnostic fields in clear, reset and restart 
indication and diagnostic packets. 


E.1 DIAGNOSTIC CODES 


TABLE E_1 DCE Diagnostics 


ow 
outs 
ct 
ul 


Decimal 
(Notes 1, 2 and 3) 8 
No Additional Information 0 
Invalid Ps 1 
Invalid Pr 2 


Packet Type Invalid 
for state rl 
for state r2 
for state r3 
for state pl 
for state p2 
for state p3 
for state p%4 
for state p5 
for state p6 
for state p/7 
for state dl 
for state d2 
for state 


Ke ee Mew OOaoaoaeaacnce & tr OOO & 


Packet Not Allowed 
unidentifiable packet 

call on one way logical channel 

invalid packet type on a PVC 

packet on unassigned logical channel 
REJECT not subscribed to 

packet too short 

packet too long 

invalid general format identifier 
restart with nonzero in bits 1-4,9-16 0 
packet type not compatible with facility 
unauthorized interrupt confirmation 
unauthorized interrupt 


Lon 3 wo Ef oo Hew Bow am Ef an Bow Bw Bw Eom om | de fet ft fet fet fed find fat fot font fet fet ft fo fo o*- OQ 0 i 


Expired 
for INCOMING CALL 

for CLEAR INDICATION 
for RESET INDICATION 
RESTART INDICATION 


> fd ar pe tee | Ce 


Call Setup Problem 
facility code not allowed 
facility parameter not allowed 

invalid called address 

invalid calling address 


G2 D2DODQDOZO!]1QO POQDQAD!OA PGDADOGDGCADQAGQAQDQA!O AGDGMaDQQ0CeCCACQCACACAAO!|!Oo coo 

~~ Heme | OO ODQQO!]l|O DC2GAOQDOQDDOGQADDA!]O @BPQQDAQGTCADGCPA0D0O!]OGO Goo] N 
—- MOOD0O |] RFPODOO!]FYP KFPOCOCORPFR KF ROOOO!]leHK FPRODOOFRPFEFRrROAOODOO!]lFH FAO] W 
~~ ORR OO!]lH OFF OO!] FHF CFF OOrRROORrHOO!]lH GOFF OOrFPKFOOFRFOO] He FOO] 
—- OFROrFO!]FH OCROrFO]H OCOFROFOrRORKR OR OF O | H RPOR ORF OrFRORPOrFOrFO!| FH OCOFoOo |] & 


hee COOOO OC He COOCOOSOG Re RK Re RRR OOOoOoOoOaAao Go pat @ 


| © Qoooeoa - fat fond fot fd fe ad fa frat fet fed fat fat pnt feet fet fant ped fd ft S&S egeoooo0cn”c”oeoooroqooooqoo fo ] Qoo On 
Oo-oaona°oeea bee 
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TABLE E_1 DCE Diagnostics — Continued 


Co 

~l 
Oo 
ate 
rr 
ui 


Pesinat 
80 


6.5 4 3:2 1 

Call clearing problem 0101 00 90 9 

non-zero address lengths field 0101 0001 

non-zero facility length field 0101 0901 0 

0101 1111 

Not Assigned 011 000 0 

o110 1111 

Not Assigned 011 000 0 

0111 1111 

Reserved for Network Specific Diagnostics 100 000 0 

Liitiiiii2 

Note: 

1. Not all diagnostic codes need apply to a specific network, but those used are as 


coded in Table E_1l. 


A given diagnostic need not apply to all packet types (i.e., reset indication, 
clear indication, restart indication and diagnostic packets). 


The first diagnostic in each grouping is a generic diagnostic and can be used in 
place of the more specific diagnostics within the grouping. The decimal '0' 
diagnostic code can be used in situations where no additional information is 
available. 


4. (Text deleted). 
EFERENCES 
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networks, Vol. VIII, Fascicle VIII.2, Rec. X.1. 

C2] CCITT Recommendation International user services and facilities in public data 
networks, Vol. VIII, Fascicle VIII.3, Rec. X.2. 

C3] CCITT Recommendation Hypothetical reference connections for public synchronous 
data networks, Vol. VIII, Fascicle VIII.3, Rec. X.92. 

C4] CCITT Recommendation Call progress signals in public data networks, Vol. VIII, 


Fascicle VIII.3, Rec. X.96. 
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F.0 APPENDIX F: DTE DIAGNOSTICS 


Codes transferred in the diagnostic code field of CLEAR, RESET AND RESTART REQUEST 
packets generated IBM SNA X.25 DTEs on SNA-to-SNA connections convey the meaning 
indicated in Table F_l. 


F.1 DTE DYAGNOSTIC CODES ON SNA-TO-SNA CONNECTIONS 


TABLE F_1 ODTE Diagnostics 
(Notes 1, 2 and 3) 


Decimal 


0o 
w 
rt 
in 


-~ fom | ed CF dl eed @? co O-m OO = oor KK OOF KY oor Fr Ooo ed oe fom ] Ro 


ao; ui 


Normal Initialization or Termination 


Invalid LLC Type 


Invalid Packet Type (General) 
for State rl 
for State 
for State 
for State 
for State 
for State 
for State 
for State 
for State 
for State 
for State 
for State 
for ' State 


DCE Timer Expired (General) 


2 Q21lao aoqaa!lo oovcoa0a lO oomqndqgegcCOOCDOAOAOOITAa 2G @& 

—- ml ao B2QOQQGQDlo TPADOO!lO @B@AQQQGDGAQaQGeCOGDeGAOAO!®S® a2 oO[f[ N 
rom ee ee ee — 2-H a ee — 2 ro 
O- oO] es RR eRe 1 Oe CODD | Me RR eee eee eee | Oe Oe 

m- O1lre-e QBOOOO!]H:s BOC OO ] Re RR Re Hr OOOO COCOO!] eR: ee Oo] aS 
m= olf emoacooa0o!]Y KFPeODDO!]Y FPR OQOORP FRR rR OOOO] RY F&F oO] Ww 
~~ of GrROrRO!]lH GCFOFO!]|RHK KPORORFORP OF OrFOrFO!]TH C2 2] & 


32 
Incoming Call 33 
Clear Indication 34 
Reset Indication 35 
Restart Indication 3 
47 
DTE Timer Expired (General) 48 
Call Request 49 
Clear Request 50 
Reset Request 51 
Restart Request 52 
63 
Unassigned (General) 64 
79 
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TABLE F_1 DTE Diagnostics — Continued 


Q@LLC Error (General) 
Undefined C-—field 
snexpected C-—field 
Missing I-field 
Undefined I-field 
I-field Too Long 


Frame Reject Received 

Header Invalid 

Data Received in Wrong State 
Time-out Condition 


PSH Error (General) 
Sequence Error 
Header too Short 
PSH Format Invalid 
Command Undefined 
Protocol Invalid 
Data Received in Wrong State 


Time-out Condition 


PAD Error (General) 
PAD Access Facility Failure 
SDLC FCS Error 

SDLC Time-—out 

SDLC Frame Invalid 
I-field too long 

SDLC Sequence Error 
SDLC Frame Aborted 
SDLC FRMR Received 
SDLC Response Invalid 


Invalid Packet Type 
PAD Inoperable 


Product Specific 


Network Specific 
DDX-P RNR Packet Received 


Packet Not Allowed (General) 
Invalid 'M' bit Packet Sequence 
Invalid Packet Type Received 
Invalid Packet on PVC 
Unassigned LC 
Diagnostic Packet Received 
Packet too short 
Packet too long 
Invalid GFI 
Not Identifiable 
Not Supported 
Invalid Ps 
Invalid Pr 
Invalid 'D" bit Received 
Invalid '@" bit Received 
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| os 
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TABLE F_1 DTE Diagnostics — Continued 


0° 
w 
ct 
ul 


= oS RR OOF KR OOrP KR OOF FOO -— — OS —~ KFOoOOorFerH OOo _ ao N 


DTE Specific (CNPSI Gate/Date) (General) 
No LU-to-LU Session 


DTE Specific (General) 
Termination Pending 
Channel Inoperative 
Unauthorized Interrupt Confirmation 
Unauthorized Interrupt Request 
PU CPVC) Not Available 
Inactivity Time-Out 


5 
1 
1 
i 
0 
0 
0 
0 
0 
0 
0 


Resources (General) 
Buffers depleted 
PIU too long 


Local Procedure Error (General) 
Packet with LC=0 not Received 
Restart or Diagnostic Packet on LCI#'0° 
INCOMING CALL Received on Wrong LC 
Facility not Subscribed 
Packet Not RESTART or DIAG on LCI='0!° 
Facility Parameters not Supported 
Facility not Supported 
Unexpected Calling DTE 
Invalid 'D' bit Request 
RESET INDICATION on Virtual Call 
Invalid Protocol Identifier 
Connection Identifier Mismatch 
Missing Cause/Diagnostic Code 


- eaoaocoeooocaocoaocoooaqoaoo fb 0 nt fot fmt Oe 


Remote Procedure Error (General) 


OO ee ed ed oe Oe od ed ed od ood ed ol 
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1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
i 
1 
1 
1 
1 
1 
1 
| 
1 
1 
1 
i 
1 
1 
1 
1 
1 
1 
1 
1 
1 


(to 


Note: 

1. All diagnostic codes are not necessarily used by all DTEs, but those that are used 
have the meaning indicated. 

2. the first diagnostic in each grouping is a generic code that may be used in place 
of the more specific codes within the group. 

3. These codes, set by transmitting DTEs, in CLEAR, RESET and RESTART packets are 


normally delivered to the remote DTE in a corresponding INDICATION packet by DCEs. 
However, DCEs may override DTE requests. In this event, DCEs place a non-zero 
Cause Code in the Cause field and insert the network Diagnostic Code (see Appendix 
E) in the Diagnostic Code field of the resulting INDICATION packet delivered to 
the remote DTE. 
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G.0 PENDIX G: PACKET LEVEL DTE ACTIONS 


Actions taken by DTEs on receipt of packets in a given state of the DTE/DCE interface 
as perceived by the DTE. 


G.1_ DTE STATE/ACTION TABLES 


TABLE G_1 — Special Situations 


The characters after the '"#' indicate the diagnostic code to be 
reported (See attachment F). 


Packet from DCE Any State 
Length < 2 octets ADVISE #166 


Packet with Incorrect GFI | ADVISE #168 
Packet on Unassigned LC ADVISE #164 


DIAGNOSTIC Packet Received ADVISE #165 
| | CNote) 


Any packet with correct GFI on assigned LC See Table G2 


ADVISE: DTEs discard the received packet and report the condition to a higher 
level using the indicated Diagnostic Code. No state transition takes place. 


DTEs discontinue normal packet processing when an error condition is encountered. 
Thus, only one diagnostic code is indicated for a single packet. The order in which 
packets are processed is not specified, therefore, a given packet containing 


multiple errors could result in different diagnostic indications when processed by 
different DTEs. 


Note: IBM SNA X.25 DTEs also report the contents of the Diagnostic Code and 
Explanation fields to a higher level. 
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TABLE G_2: 


Actions taken by DTEs 


on receipt 


of packets in given 


states of the packet level DTE/DCE interface as perceived 


by the DTE: 


Restart procedure for assigned LCs 


The codes in parentheses (In) ‘specify the new states to be entered. | 


The characters after the '#' 
reported (see Attachment F). 


Received Packet 


RESTART 
INDICATION 


DCE RESTART CONFIRMATION 


ANY PACKET on Logical Channel 
not equal to Zero 


DCE RESTART CONFIRMATION or 
RESTART INDICATION on 
Logical Channel not equal to Zero 


PACKET ON Logical Channel Zero 
not RESET INDICATION, RESTART 
INDICATION or DIAGNOSTIC 


UNIDENTIFIABLE PACKET 


UNSUPPORTED PACKET 


indicate the 


diagnostic code to be 


NORMAL NORMAL 
(r3) (pl or dl) 
Note 


ERROR NORMAL 
Cr2) Cpl or dl) 
#17 Note 


Table DISCARD 
G_3 Cr2) 


Table ADVISE 
G_3 Cr2) 
#226 


ADVISE 
Cr2) 
#229 


Table ADVISE 
G Cr2) _ 
#169 — 


Table ADVISE 


0 
G_3 C(r2) 
#170 


NORMAL: DTEs process the received packet in accordance with defined procedures. 
ADVISE: DTEs discard the received packet and report the condition to a higher 
level using the specified diagnostic code. No logical channel state transition 
occurs. 

ERROR: DTEs discard the received packet, report the error condition to a higher 


level and transmit a RESTART_REQUEST packet across the DTE/DCE interface placing all 
the logical channels in the DTE_RESTART_REQUEST state (r2). 
DISCARD: 


DTEs discard the received packet. No state transition takes place. 


Note: State'pl for virtual calls or state dl for permanent virtual circuits. 
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TABLE G_3: DTE actions on receipt of packets in given states of the 
packet level DTE/DCE interface as perceived by the DTE: 
Call Set-up and Clearing on assigned Logical Channels. 


The codes itn parentheses (ln) indicate the new state to be entered. 
The characters after the '#" indicate the diagnostic codes to be 
reported (see Attachment F). 


DATA CALL 
XFER COLL 


p4 p5 


ERROR} ERROR} DISC ERROR 
(p6) (p6) (p6) (p6) 
#23 #24 #26 


ERROR|NORMAL] ERROR{ ERROR{NORMAL| DISC 
Cp6) (p4) (p6) (p6) (p4) (p6) 
#20 #22 #23 
CLEAR NORMAL | NORMAL | NORMAL | NORMAL | NORMAL | NORMAL | NORMAL 
INDICATION (p7) Cp7) (p7) (p7) (p77) (pl) 
DCE CLEAR DISC ERROR] ERROR] ERROR| ERROR{NORMAL| ERROR 
CONFIRMATION (pl) (p6) (p6) (p6) (p$) (pl) (p6) 
#21 #22 #23 #24 #26 
OTHER PACKETS ERROR| ERROR TABLE{ ERROR} DISC ERROR 
(p6) (p6) G_4 (p6) (p6) (p6) 
#20 #21 #24 #26 


NORMAL: DTEs process the received packet in accordance with defined procedures. 


Packet 
Received 


INCOMING 
CALL 


CALL 
CONNECTED 


ERROR: ODTES report an error situation, using the indicated diagnostic code, and 
clear the virtual call or reset the permanent virtual circuit by transmitting a 
CLEAR/RESET REQUEST packet across the DTE/DCE interface. Some DTEs may optionally 
restart the DTE/DCE interface by transmitting a RESTART REQUEST packet. 


DISC: The packet is discarded. No state transition occurs. 


Note: 


1. For one-way outgoing logical channels, DTEs transmit CLEAR_REQUEST with the 
diagnostic code #227 on SNA-to-SNA connections. 


2. For packet format errors, DTEs transmit a RESTART_REQUEST with the diagnostic 
code #162 on SNA-to-SNA connections. For unsubscribed facilities, DTEs transmit 
a CLEAR REQUEST with the diagnostic code #228 on SNA-to-SNA connections. 


DTEs transmit a CLEAR REQUEST (Con SNA-to-SNA connections, with the diagnostic 
code #208 if they cannot accept the call for some internal logical reason; and 
with diagnostic. code #12 if the calling DTE has indicated some unsupported 
end-to-end function Ce.g., differing PSH support)). 


APPENDIX G: PACKET LEVEL DTE ACTIONS | II-G-3 


SNA/X.25 DTE/DCE Interface 


TABLE G_4: DTE actions on receipt of packets in given States of the 
. packet level DTE/DCE interface as perceived by the DTE: 
Data transfer, CInterrupt,] CFlow Control and Reset) on 

Assigned Logical Channels. : 


The codes in parentheses (ln) specify the new states to be entered 
The characters after the '#* indicate the diagnostic codes to be 
reported (see Attachment F). 


DTE DCE 
RESET RESET 
Packet REQUEST INDICATION 


d2 


NORMAL 
Cdl or p6) 


d3 


ADVISE 
(d3) 
#45 


Received 


RESET INDICATION 


di 
NORMAL 
Cd3) 


DCE RESET CONFIRMATION ERROR NORMAL ERROR 
Cd2) Cdl or p6) (d2) 

#27 #29 

DATA, CINTERRUPT,] and NORMAL DISCARD ERROR 
FLOW CONTROL Cdl) (d2) (d2) 
#29 


INVALID PACKET TYPE, 
Q@LLC ERROR, PSH ERROR or 
PACKET NOT SUPPORTED 


DISCARD 
(d2) 
See Attachment F for 
Diagnostic Codes 


NORMAL: DTEs process the received packet in accordance with defined procedures. 


ADVISE: DTEs discard the received packet and report the condition to a higher 
level using the indicated diagnostic code. 


ERROR: DTEs discard the packet, report the error condition using the indicated 
diagnostic code and clear the virtual call or reset the permanent virtual circuit by 
transmitting a CLEAR/RESET_REQUEST packet across the DTE/DCE interface. 


Some DTEs may optionally restart the DTE/DCE interface by transmitting a 
RESTART_REQUEST packet. 


DISCARD: The packet is discarded. No logical channel state transition occurs. 
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H.O APPENDIX H> PSH LOGICAL LINK CONTROL 


Logical Link Control (LLC) using Physical Services Headers (PSH) 


IBM SNA X.25 DTEs that communicate with remote IBM 5973 Network Interface Adapters 
(NIAs) use the Physical Services Header (PSH) to perform the logical link control 
(LLC) functions described in this appendix. 


H.1 PHYSICAL SERVICES HEADER FORMATS 


PSHs have the structure depicted in Figure H-1. 


Poe meta top ta tay 


Octet |SNA Format Identifier (FID FOX) 
0 1 1 1 1 
: 
2 PSC or PSC Modifier (PSXID and PSTEST Information field as 
defined for SDLC XID and TEST, respectively) or Data 
3 
: | | PSC Modifier or Data { 
n 
Legend: 
R —- Reserved CPI — Control Present Indicator 
(Control = PSC or PSC Modifier 
SI - Segmenting Indicator 
b'l' — More segments to b'1l"' — Control Present 
follow b'0" — Control Not Present 
b'O0' — Last or only segment 
PSC — Physical Services Command 
PSI - Packet Sequence Indicator 
x'02' = PSDISC CDISCONTACT) 
b'1l* — Octet 1 = SN 
—- Octet 2 = PSC or Data x'04" = PSXID CEXCHANGE ID) 
b'Q" — Octet 1 = PSC or Data x'06" = PSTEST CTEST) 
x'08" = PSCONTACT CCONTACT) 
~ Octet 2 = PSC Modifier 
or Data SN -— Data Packet Sequence Number 


Note: Octet 2 of the PSCONTACT and PSTEST responses transmitted by a 
Secondary/Remote IBM 5973 NIA contains the SDLC station address. 


Figure H-1. Physical Services Header (PSH): Formats 


PSHs are inserted in front of SNA PIUsS transmitted across the network(s), for: 


1. Adjacent SNA node physical services - traditional SNA functions such as XID, SNRM, 
and TEST that are mandatory for IBM SNA X.25 DTEs. Adjacent SNA node physical 
services are performed according to the same criteria as the equivalent normal 
response mode SDLC functions. 


2. Data Segmentation - permitting IBM SNA X.25 DTEs to segment user data into packets 
when the 'M’ bit procedure is not used. 


3. sequence Numbering - an optional end-to-end packet sequence numbering function to 
provide for the detection of lost, duplicated or disordered data packets. 
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IBM SNA X.25 DTEs that must remotely connect to an IBM 5973 Network Interface Adapter 
CNIA) that support only PSH LLC must implement QLLC with '"M' bit segmenting/segment 
reassembly as well as PSH LLC. 7 


H.2 OPERATING RULES 


Rules for use of Physical Services Headers on SNA-to-SNA connections, include: 


1. 


The first octet of the Call User Data field in call control packets is coded with 
bits 8 through 1 = x'C2" or x'C6" to identify SNA-to-SNA connections that use 
PSHs. 


The PSH is used for segmentation. The 'M’ bit is not to be set equal to "1' by 
DIEs in data packets when the PSH is used for segmentation. 


The maximum User Data field length must be the same at both the local and remote 
DTE/DCE interfaces. 


Although either DTE may use the same PSH commands, the use of these 1s asymmetric. 
One DTE, designated 'F', may send PSXID, PSTEST or PSCONTACT at any time. The 
other DTE, designated 'R', must send PSXID, PSTEST or PSCONTACT only after having 
received the corresponding command. 


Either DTE may send PSDISC at any time. 


After sending PSXID, PSTEST or PSCONTACT, 'F* waits for a reply from 'R'. There is 
a timeout associated with this wait. 


If 'F' receives a PSXID, PSTEST or PSCONTACT command which 1s not in response to a 
corresponding command ‘'F' sends PSDISC or may terminate the virtual circuit by 
clearing, resetting or restarting. 3 


When either 'F' or 'R' receives a PSDISC it responds by sending a FSDISC command 
Cunless a PSDISC collision has occurred) or else terminates the virtual circuit. 


PSH LLC commands and responses are initiated by the same higher-level events that 
initiate their SDLC counterparts (see Figure 20 in §-8). 
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1.0 APPENDIX YI: SNA-TO-NON SNA CONSIDERATIONS 


Architectural considerations for SNA-to-non_SNA connections 

Three implementations approaches are defined for SNA-to-non_SNA connections. In the 
first one, virtual circuit functions are mapped to an SNA session at the SNA boundary 
node permitting support of non_SNA nodes across packet-switched networks with limited 
effect on the subsystems. The second approach provides a transparent path between the 
X.25 DTE/DCE interface, residing in some SNA boundary node, and an application program 
interface which handles all the packets defined in CCITT Recommendation X.25. The 


third approach can provide various degrees of transparency and mapping for X.25 
virtual circuit functions. 


I.) IMPLEMENTATION APPROACH 1 


A Packet-Mode DTE implemented in an SNA PU.T4 or PU.T5 node acts as a boundary function 
providing conversion between a virtual circuit and an SNA session. The non-SNA remote 
nodes may establish several virtual circuits across the network to/from the SNA 
PU.TS/T5. To each of these virtual circuits, there corresponds a session acting aS a 
transportation mechanism towards some application interface in some SNA host node. 
The half session in the PU.T4/T5 will have the appearance of either a SLU or a PLU, 
depending on the direction of call setting. This is to permit future extension to the 
SNA pass through function. . 
The following mappings are possible: 
° INCOMING CALL packets may be mapped into either: 

1. Request Contact (with a pseudo ID); or, 


2. Unformatted INITSELF, carrying the contents of the call user data field and 
the calling DTE address to the USS of an SSCP that controls the PU.T4/T5. 


e +RESP/BIND is mapped into CALL ACCEPTED. 

® CONNOUT and BIND provide information to create CALL REQUEST. 

e CALL CONNECTED is mapped into +RESP/BIND. 

e CLEAR INDICATION is mapped into UNBIND. 

e UNBIND is mapped tnto CLEAR REQUEST. 

e RESET INDICATION is mapped into an extended SNA CLEAR. 

® SNA CLEAR extended 1s mapped into RESET REQUEST. 

® INTERRUPT is mapped into SIGNAL, and vice versa. 

° The data field of DATA packets are mapped into RUs. 

e Complete packet sequences need not necessarily be reassembled in the PU.T4/T5 
before transmission within SNA. Chaining can be used within SNA in order to 
relate unassembled PIUS which belong to the same packet sequence. 

° No direct mapping can be established between the X.25 window rotation mechanism 
for flow control and the SNA pacing mechanism. The PU.T4/T5 will act as an 
intermediate buffer and will handle flow control on each network as a function of 
its general memory assignment strategy by use of the appropriate mechanism on each 
side. 


® The 'D® bit is mapped to the form of RESPONSE REQUESTED bits in the RH, where: 


- *D'="'0" corresponding to the exception response indicator set to "1°. 
= "D'='1'4+corresponding to the definite response indicator set to "1'. 


® Other higher level SNA functions - such as set and test sequence numbers, brackets 
and function management header protocols - are not mappable to X.25. 
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IT.2 IMPLEMENTATION APPROACH 2 


A. possible architecture to permit transparent handling of X.25 is based on the 
provision of a single session path between the SNA boundary node and the Sreelescren 
as depicted in Figure I-2. 


All the virtual, circuits are multiplexed on this single session flow. Denu’eipiexine 
is performed, by analysis of the logical channel number in the packets, by the 


application. All of the functions of X.25, being thus handled transparently to SNA, 
can be supported in this environment. 


I.3. IMPLEMENTATION APPROACH 3 


This hybrid approach is a mixture of approaches 1 and 2. Various degrees of X.25 
transparent and mapped function can be acheived on given SNA sessions. 
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_J.0 APPENDIX J: LINK LEVEL DTE ACTIONS 


Actions taken by DTEs for various link layer events in given Link Channel states of the 
Link Layer interface as perceived by the DIE 


Details on the operation of the Link Layer (Level 2) Balanced Link Access Procedure 
CLAPB) protocols are given in the form of State/Action tables, in Tables J-1, -2, -3 
and -4. Actions to be taken by the DTE as a result of a particular stimulus are shown 
at the intersection of the various states of the Link Layer interface and the stimuli. 
Stimuli for the LAPB protocols include the events, commands and responses defined in 
"LAPB Protocol Stimuli" on page II-J-3. The Link Layer states Cidentified by single 
lower case letters ‘'(€s)' and the sub-states/options/conditions Cidentified by 
superscripts with the state designations "(5°,?,,,%)") are described in "Link Layer 
(level 2) States.” 


Information contained at these intersections show the actions to be taken Cindicated 
by two uppercase letters enclosed in parentheses 'CAA)'), the frame types to be sent 
(if any, indicated by two uppercase letters 'FF') and the new Link Layer states to be 
entered Cif any, indicated by lower case letters enclosed in parentheses '(s)'). A 
note number reference '&n" is also included when further explanation is required. 


The frame type to be sent, "FF', is any of the commands and responses depicted in Table 
II-3 of §-2.4%.3. Supervisory frames (RR, RNR or REJ identified by RR, NR» and RJ, 
respectively) are assumed to be responses unless otherwise indicated by‘the lower case 
letter ‘'c' following the frame type to be sent, '‘'FFce'; and the setting of the 
Poll/Final 'P/F" bit is indicated by '°' or '!' ('FF°,2)". No frame is transmitted 
when no frame type to be sent, '"FF*', is indicated. 


The new Link Layer state(s), (5s), indicates which of the defined Link Layer states is 
to be entered following transmission of the frame type to be sent, "FF'. The Link 
Layer interface remains in the current state when no new Link Layer state to be 
entered, (5s), 1s indicated. 


Alternative actions, frame types to be sent and new link layer states Cidentified by 
A, F or S, respectively, in the right most position of the STATES column) are shown for 
sub-states/options/conditions only when they differ from those shown for the base 
states. 


The various Link Layer states/sub-states/options/conditions and the 
events/commands/responses shown in Tables J-1, -2, -3, and -4 are summarized as 
follows: 


J.1 LINK LAYER (LEVEL 2) STATES 


DISCONNECTED State [DISCD - (a) ] 


Link stations assume the Link Layer DISCONNECTED state (a) (see § 2.4.5.4) when the 
Physical Layer initially becomes operational, after having received a DISC command and 
returned a UA response, after having received a UA response to a transmitted DISC 
command; or, optionally, after having detected the Idle Channel condition on the 
incoming link channel, if a flag sequence is not received within a specified period of 
time, Ti (see §§-2.2.12.2 and 2.4.11.5). 


LINK SET-UP State CSETUP - (b)] | 

Link stations desiring to CredJinitialize the link layer transmit a SET ASYNCHRONOUS 
BALANCED MODE CSABM) command and assume the Link Layer LINK SET-UP state (b) until an 

See ey UA or DM response is received from the remote link station (see 
-2.4.5.1) | 

FRAME REJECTION State CFRJCN - (c)]J 

Link stations having transmitted a FRMR response assume the Link Layer FRAME REJECTION 
state (c) until reset by the remote link station or until local recovery action is 
initiated (see §§-2.3.4.10, 2.3.5.6 and 2.4.10). 


DISCONNECT REQUESTED State EDCRQD - (d)] 
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Link stations having transmitted a DISC command assume the Link Layer DISCONNECT 
REQUESTED state (d) to wait for a UA response from the remote link station (see 
§-2.4.5.3). 

INFORMATION TRANSFER State [LIFTRN - (e)] 

Link stations having received a UA response to a transmitted SABM command or having | 
returned a UA response to an SABM command from the remote link station assume the Link 
Layer INFORMATION TRANSFER state (e) (see §-2.4.5.2). 

REJECTION State CREJCN - (f)] 

Link stations having transmitted a REJ command/response requesting retransmission of 


an out-of-sequence frame(s) enter the Link Layer REJECTION state (f) (see §§-2.3.5.2, 
2.3.5.3 and 2.4.6.5). 


CHECKPOINT RECOVERY State [CPRCV - (gq) ] 

Link stations enter the Link Layer CHECKPOINT RECOVERY state (g) upon expiration of 
Reply Timer, Tp, and transmit an appropriate Supervisory command.frame with "P=1' (see 
§§-2,3.5.4 and 2.4.6.8). 

CHECKPOINT RECOVERY/REJECTION State LCPRRJ - (h)] 


The CHECKPOINT RECOVERY/REJECTION state (h) is a composite of the CHECKPOINT RECOVERY 
state (g) and the REJECTION state (f). | 


LOCAL STATION BUSY State [LBUSY - (i)]J 
Link stations having transmitted an RNR command/response, indicating their inability 
to handle additional information frames due to some internal constraint (ji.e., buffer 


limitation) assume the Link Layer LOCAL STATION BUSY state (i) (see $§-2.3..5.1 and 
2.4.6.7). 


REMOTE STATION BUSY State ERBUSY - (j3)] 


Link stations enter the Link Layer REMOTE STATION BUSY state (3) upon receipt of an RNR 
command/response from the remote link station (see §§-2.3.5.1 and 2.4.6.7). 


BOTH STATIONS BUSY State [BBUSY - (k)] 

Link stations enter the Link Layer BOTH STATIONS BUSY state (k) upon receipt of an RNR 
command/response from the remote link station while in the Link Layer LOCAL STATION 
BUSY state (1); or, after transmitting an RNR command/response while in the Link Layer 
REMOTE STATION BUSY state (j) (see §§-2.3.5.1 and 2.4.6.7). 

REJECTION“LOCAL STATION BUSY [RJNLB - (1)] | 


This state (1) is a composite of the Link Layer REJECTION state (f) and the Link Layer 
LOCAL STATION BUSY state (i) (see §§-2.3.5.1, 2.3.5.2, 2.3.5.3, 2.4.6.5, 2.4.6.7). 


REJECTION/REMOTE STATION BUSY CRJNRB - (m)] 


This state (m) is a composite of the Link Layer REJECTION state (f) and the Link Layer 
REMOTE STATION BUSY state (j) (see §§-2.3.5.1, 2.3.5.2, 2.3.5.3, 2.4.6.5, 2.4.6.7). 


REJECTION/BOTH STATIONS BUSY CRJNBB - (n)] 


This state (n) 15 a composite of the Link Layer REJECTION state (ff) and the Link Layer 
BOTH STATION BUSY state (k) (see §§-2.3.5.1, 2.3.5.2, 2.3.5.3, 2.4.6.5, 2.4.6.7). 


CHECKPOINT RECOVERY/LOCAL STATION BUSY CCPRLB - (0)] 


This state (0) 1s a composite of the Link Layer CHECKPOINT RECOVERY state (9) and the 
Link Layer LOCAL STATION BUSY state (i) (see §§-2.3.5.1, 2.4.6.7 and 2.4.6.8). 


CHECKPOINT RECOVERY/REMOTE STATION BUSY CCPRRB - (p)] 


This state (p) is a composite of the Link Layer CHECKPOINT RECOVERY state (g) and the 
Link Layer REMOTE STATION BUSY state (j) (see §§-2.3.5.1, 2.4.6.7 and 2.4.6.8). 


CHECKPOINT RECOVERY/BOTH STATIONS BUSY CCPRBB - (q)] 
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Thi, state (€q) is a composite of the Link Layer eee, RECOVERY state (g) and the 
Link Layer BOTH STATIONS BUSY state (k) (see §§-2.3.5.1, 2.4.6.7 and 2.4.6.8). 
CHECKPOINT RECOVERY/REJECTION/LOCAL STATION BUSY [CRJLB - (r)] 


This state (r) is a composite of the Link Layer CHECKPOINT RECOVERY state (9), the Link 
Layer REJECTION state (f) and the Link Layer LOCAL STATION BUSY state (i). 


CHECKPOINT RECOVERY/ZREJECTION/REMOTE STATION BUSY [CCRJRB - (s)] 


This state (s) 1s a composite of the Link Layer CHECKPOINT RECOVERY state (g), the Link 
Layer REJECTION state (f) and the Link Layer REMOTE STATION BUSY state (j). 


CHECKPOINT RECOVERY7ZREJECTION/BOTH STATIONS BUSY CCRJBB - (t)] 


This state (t) is a composite of the Link Layer CHECKPOINT RECOVERY state (g), the Link 
Layer REJECTION state (ff) and the Link Layer BOTH STATIONS BUSY state (k). 


INOPERATIVE CNOPTV - (Cu)] 


The Link Layer assumes the Link Layer INOPERATIVE state (u) when the Physical Layer is 
not operational (see §-2.4.5.1). 


SUB-STATES/OPTIONS/CONDITIONS 
Sub-states/O0ptions/Conditions applicable to the various Link Layer states include: 


° - Alternatives that may be implemented in lieu of the architecturally preferred 
procedure. 


1 - When at a convenient respond opportunity. 


2 - When a response to a command received with 'P=1" is required. 


3 - When a response is not appropriate, if desired. 


4 - When no I-frame is available for transmission or when the link level transmit 
window is full Ce.g., the number of unacknowledged I-frames is equal to 'K"). 


5 - When not prepared to continue operation with, or following, 
Credinitialization of the Link Layer interface. 


€ - When enabled and prepared to (CredJinitialize the link layer interface and 
support the transfer of information. 


7 - When not at a convenient respond opportunity and no I-frames have been 
discarded. 


6 - When at a convenient respond opportunity and one or more I-frames have been 
discarded. 


9 - When not at a convenient respond opportunity and one or more I-frames have 
been discarded. 


J.2 LAPB PROTOCOL STIMULI 


Stimuli for the LAPB protocol include the events, commands and responses described in 
the "Events,™ "Commands”™ on page II-J-4 and "Responses" on page II-J-6, respectively. 


J.2.1 Events 


Plopt (Physical Layer Operational) 


The Physical Layer Operational (PLopt) event represents a transition of the Physical 
Layer (level 1) to the operational state (see §-2.4.5.1). 


Lstrt (Link Start) 
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The Link Start (Lstrt) event represents instruction from a higher layer to set-up 
Cinitialize/restart) the Link Layer interface (see §-2.4.5.1). 


Lstop (Link Stop) 


The Link Stop (Lstop) event represents instruction from a higher layer to terminate 
Link Layer operation (see §-2.4.5.3). 


PLnop (Physical Layer Inoperative) 


The Physical Layer Inoperative (PLnop) event represents a transition of the Physical 
Layer (level 1) to the inoperative state (see §-2.4.5.1). 


Ebusy Cloce] Station Entering Busy Condition) 

The Local Station Busy (Ebusy) event occurs when the local station can not accept 
additional I-frames because of some internal constraint (e.g., buffering limitations, 
see §-2.4.6.7) 

Lbusy (Local Station Exiting Busy Condition 


The Local Station Exiting Busy (Lbusy) event occurs when a local station recovers from 
a busy condition (see §-2.4.6.7). 


TpExp (Timer Tp Expiration) 


He Timer Tp Expiration CTpExp) event occurs upon expiration of Reply Timer, Tp (see 
-2.4.11.1) 


TnExp (Query Timer Tn Expiration) 
The Query Timer Tn Expiration (TnExp) event occurs following a period of link 


Sat aed lasting for the duration of Query Timer, Tn (see §§-2.3.4.4, 2.4.6.6 and 
2.4.11.1). 


FtExp (Nested Time-out Expiration) 


This Nested Time-out Expiration event (FtExp) occurs when the maximum number of 
repetitions (Nd) is exhausted (see §~-2.4.11.1). 


TlFrm (Illegal Frame) 

The Illegal Frame (IlFrm) event represents the correct receipt of a frame containing a 
command/response that is invalid or not implemented, an information field that exceeds 
the maximum permissible length, an invalid Nr, an information field that is not 
permitted, or an S$ or U frame of incorrect length (see §§-2.3.4.10 and 2.3.5.6 


InFrm CInvalid Frame) | 

The Invalid Frame CInFrm) event represents the receipt of a frame not properly bounded 
by two flags, having fewer than 32 bits between flags (see §-2.2.9) or one containing 
an address other than 'A' or '"B’ (see §-2.4.2). 

RLchi (Receive Link Channel Idle) 

The Receive Link Channel Idle (RLchi) event occurs following detection of the idle 
condition if a flag sequence is not received within the Idle Time-out period, Ti (see 
§§-2.2.12.2 and 2.4.11.5). 


TLchr (Transmit Link Channel Ready) 


The Transmit Link Channel Ready (TlLchr) event occurs. faollowing transmission of the 
last bit of the current frame. 


J.2.2 Commands 
DC° (Disconnect with 'P=0") 


co Gas a DISCONNECT CDISC) command frame with the poll (CP) bit set to zero (see 
-2.3.4.7). 
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DC? (Disconnect with "P=1") 


Aa lat ae a DISCONNECT CDISC) command frame with the poll (P) bit set to one (see 
-2.3.4.7). 


IR° (Requested Information Frame with 'P=0') 


Represents the requested information command frame with the poll (P) bit set to zero 
(see §-2.4.6.5). 


IR? (Requested Information Frame with 'P=1") 


Represents the requested information command frame with the poll (P) bit set to one 
(see §-2.4.6.5). 


IS? (In-Sequence Information Frame with 'P=0") 


Represents the next in-sequence information (I) command frame with the poll (CP) bit 
set to zero, if available, (see §-2.4.6.2) otherwise continuous flag sequences. 


IS? (In-Sequence Information Frame with 'P=1") 


Represents the next in-sequence information CI) command frame with the poll (P) bit 
set to one, if available, (see §-2.4.6.2) otherwise continuous flag sequences. 


NR° (Receive Not Ready with "P=0') 


Represents a RECEIVE NOT READY (RNR) command frame with the poll (P) bit set to zero 
(see §-2.3.4.4). 


NR? (Receive Not Ready with "P=1"') 


Represents a RECEIVE NOT READY CRNR) command frame with the poll (P) bit set to one 
(see §-2.3.4.4). 


RR° (Receive Ready with 'P=0") 


See ars a Receive Ready (RR) command frame with the poll (P) bit set to zero (see 
=2).3<5422)% 


RR! (Receive Ready with 'P=1") 


oe as a Receive Ready (RR) command frame with the poll (P) bit set to one (see 
=2.3.9.2)% 


RJ° (Reject with "P=0") 


ae aa a REJECT CREJ) command frame with the poll (P) bit set to zero (see 
$2364 e5) 8 


RJ! (Reject with 'P=1") 


Coo a REJECT CREJ) command frame with the poll (¢(P) bit set to one (see 
254455) s 


SE° (Out-of-Sequence Information Frame with "P=0"') 


Represents an out-of-sequence information command frame with the poll (P) bit set to 
zero (see §§-2.3.5.2 and 2.4.6.2). 


SE! (Out-of-Sequence Information Frame with 'P=1") 


Represents an out-of-sequence information command frame with the poll (P) bit set to 
one (see §§-2.3.5.2 and 2.4.6.2). 


SM° (Set Asynchronous Balanced Mode with 'P=0') 


Represents a SET ASYNCHRONOUS BALANCED MODE C(CSABM) command frame with the poll (P) bit 
set to zero (see §-2.3.4.6). 


SM! (Set Asynchronous Balanced Mode with "P=1") 


Represents a SET ASYNCHRONOUS BALANCED MODE (CSABM) command frame with the poll (P) bit: 
set :to one (see §-2.3.4.6). 
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Note: Commands followed by ‘ak’ (LL°,2ak) indicate a received frame containing an 


acknonledgement (Can Nr greater than the last Nr received) for previously transmitted 
I-frame(s). 


J.2.3 Responses 


CF (Continuous Flags) 
Represents continuous flag sequences (see §§-2.2.11 and 2.4.5.1). 


DM (Disconnected Mode with 'F=0 or 1") 


Represents a DISCONNECTED MODE (DM) response frame with the final (CF) bit ‘set to 
either zero or one (see §-2.3.4.9). 


FR (Frame Reject with 'F=0 or 1°) 


Represents a FRAME REJECT CFRMR) response frame with the final (CF) bit set to etther 
zero or one (see §-2.3.4.10). 


NR° (Receive Not Ready with 'F=0") 


Represents a RECEIVE NOT READY CRNR) response frame with the final (F) bit set to zero 
(see §-2.3.4.4). 


NR? (Receive Not Ready with '"F=1") 


Represents a RECEIVE NOT READY CRNR) response frame with the final CF) bit set to one 
(see §-2.3.4.4). 


RJ° (Reject with 'F=0") 


os ay a REJECT CREJ) response frame with the final (CF) bit set to zero (see 
~2.3.4%.3). 


RJ? (Reject with 'F=1") 


ele a a REJECT (CREJ) response frame with the final (CF) bit set to one (see 
~2.3.4.3). | 


RR° (Receive Ready with "F=0") 


Molar a RECEIVE READY CRR) response frame with the final (CF) bit set to zero (see 
-2.3.4.2). 


RR! (Receive Ready with 'F=1") 


Bey a RECEIVE READY CRR) response frame with the final CF) bit set to one (see 
-2.3.4.2). 


UA (Unnumbered Acknowledgement with "F=0 or 1") 


Represents an UNNUMBERED ACKNOWLEDGEMENT (CUA) response frame with the final (CF) bit 
set to either zero or one (see §-2. 3.4.8). 


Note: Responses followed by ‘ak’ (LL°,4ak) indicate a received frame containing an 


acknowledgement (Can Nr greater than the last Nr received) for previously transmitted 
I-frame(s). 


J.3 ACTIONS 


CAA) Advance Transmit Window and Acknowledge Receipt 
Advance the lower transmit window edge to the Nr contained in the received frame, 


acknowledge receipt (Cincrement Vr by '1'°') of the received frame and pass the 
information field to a higher layer (see §§-2.4.6.2, 2.4.6.4 and 2.4.6.8). 
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(AD) Advance Transmit Window and Discard Frame 


Advance the lower transmit window edge to the Nr contained in the received frame and 
discard the information field (see §§-2.4.6.2.2 and 2.4.6.4). 


CAF) Acknowledge Receipt and Forward I-field 


Acknowledge receipt (increment Vr by "1") of the received frame and pass the 
information field to a higher layer (see §-2.4.6.2.1) 


(AL) Assure Link 


Assure link operation by transmitting a command frame with 'P=1' and starting reply 
timer, Tp (see §§-2.4.3 and 2.4.6.8). 


(AR) Advance Transmit Window and-Resume Transmission 
Advance the lower transmit window edge to the Nr contained in the received frame and 


resume sequential transmission of information frames (see§§- 2.4.6.4, 2.4.6.6 and 
2.4.6.7). 


(AS) Advance Transmit Window and Suspend Transmission 


Advance the lower transmit window edge to the Nr contained in the received frame and 
suspend sequential transmission of information frames (see §§-2.4.6.4 and 2.4.6.6). 


CAW) Advance Transmit Window 


sabia as the lower transmit window edge to the Nr contained in the received frame (see 
-2.4.6.4). 


CAX) Advance Transmit Window and Set Send Sequence 

Advance the lower transmit window edge to the Nr contained in the received frame and 
set the send sequence variable (Vs) equal to the value of Nr contained in the received 
frame (see §§-2.4.6.4 and 2.4.6.5). 

(DF) Discard Frame 


Discard the information field contained in the received frame (see §§-2.4.6.3 and 
2.4.6.7). 


(DL) Disconnect Link 

Initiate the link disconnection procedure described in §-2.4.5.3. 
CIC) Increment Count 

Increment the retransmission count (see §-2.4.11.2). 

CIF) Ignore Frame 

Ignene the received frame (see §§-2.2.9, 2.3.5.5 and 2.4.2). 
(TH) Inform Higher Layer Protocols 


Higher layer protocols may be informed of the event/condition/state using DIE specific 
internal signalling mechanisms (see §§-2.4.3.1, 2.4.5.1, and 2.4.5.3). 


CIL) Initialize Link 
Set-up Cinitialize) the link in accordance with the procedures described in §-2.4.5.1. 
(LE) Logical Local Error 


Logically erroneous local conditions may be reported to higher layer protocols and the 
current state maintained pending further instructions. 


(PC) Product Criteria 


poeeteee a. the FRMR response until recovery based on local product criteria is 
initiated. 


(NS) No Specific Action 
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No specific local DTE action required. 


CRE) Remote Procedure Error 


Logically erroneous remote conditions may be reported to higher layer protocols and 
the current state maintained pending further instructions. 


(RL) Reset Link 

Reset (re-initialize) the link in accordance with the procedures described in §-2.4.9. 
CRT) Resume Transmission 

Resume sequential transmission of information frames (see §§-2.4.6.2.1 and 2.4.6.7). 
CSR) Set Send Sequence and Resume Transmission 

Set the send sequence variable (Vs) equal to the value of Nr contained itn the received 


frame and resume sequential transmission of information frames (see §§-2.4.6.5 and 
2.4.6.7). 


($5) Set Send Sequence 


Set the send sequence variable (Vs) equal to the value of Nr contained in the received 
frame (see §-2.4.6.4) 


2 (ST) Suspend Transmission 

Suspend sequential transmission of information frames (see §-2.4.6.6). 

(TR) Time Reply 

Start reply timer, Tp, if it is not already running (see §-2.4.11). 

(XR) Advance Window, Set Send Sequence and Resume Transmission | 
Advance lower transmit window edge, set the send sequence variable (Vs) equal to the 


value of Nr contained in the received frame and resume sequential transmission of 
information frames (see §§-2.4.6.4 and 2.4.6.5). 
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Table II-J-1: Actions taken as a result of Events occurring in various states 
of the Link Layer Interface as perceived by DTEs 


_ EVENTS 


(LE) 
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Table II-J-la: Actions taken as a result of Events occurring in various states 


of the Link Layer Interface as perceived by DTEs 


EVENTS 
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Table II-J-lb: Actions taken as a result of Events occurring in various states 
of the Link Layer Interface as perceived by DTEs 
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Table II-J-le: Actions taken as a result of Events occurring in various states 
of the Link Layer Interface as perceived by DTEs 


EVENTS 


(LE) |CLE) (CLE) FCLE) FCLE) JCLE) CLE) 
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Table II-J-2: Actions taken as a result of Information 
Command Frames received in various states of 


the Link Layer Interface as perceived by 
DTEs 


4 
" 
° 
wy 
x 


ES DS Sc 
& °o 
; | 
1 
—{ 
x 
z 
> 
TI 
—_ 
> 
> 
w 


SETUP (DF) 


oS 
tet 
o 7] 
QO 
o 


FRJCN 


DCRQD 


p= 4 
ar 


( 
{ 
vl > 


(DF) {(€AD) 
RJ RJ? | Ry? 
H20f)) CF) R2C4) 


(AD) | CDF) 
RJ Ry} 


(AA) |CAF) |CAA) | CDF) |CAD) 
RR RR? | rR? | RR RR 
#2(g) (g)]#2(g) - 1%2 —- 

(AD) (AD) 

NR? NR 

2 $2 - 

(AA) (AA) |(DF) |€AD) | CDF) | (AD) 
RR RR? | RJ RJ RJ? | Ro? fT 
#2 - #2 —- Cm) ]820m)] Om) 1 820m) 


ia aes ES 
o 


APPENDIX J: LINK LEVEL DTE ACTIONS | II-J-13 


SNA/X.25 DTE/DCE Interface 


APPENDIX J: 


Table II-J-2a: Actions taken as a result of Information 
Command Frames received in various states 


of the Link Layer Interface as perceived 
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Table II-J-3: Actions taken as a result of Supervisory and Unnumbered Command Frames received in 
various states of the Link Layer Interface as perceived by DTEs 


Peat ean] ot fate] oe Dean] owt [in] oo 


(ST) |CAS) 
RR? | RR?! 
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Table II-J-3a: Actions taken as a result of Supervisory and Unnumbered Command Frames received in 
various states of the Link Layer Interface as perceived by DTEs 


- iz . peepee - a 
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Table II-J-3b: Actions taken as a result of Supervisory and Unnumbered Command Frames received in 
various states of the Link Layer Interface as perceived by DTEs 


COMMAND 


APPENDlx J: LINK LEVEL DTE ACTIONS 3 Llog=17 


SNA/X.25 DTE/DCE Interface 


Table II-J-3c: Actions taken as a result of Supervisory and Unnumbered Command Frames received in 
various states of the Link Layer Interface as perceived by DTEs 


COMMAND 


een (LE) J|CLE) [CLE JCLE) FCLED FCLE) |CLE) CLE) J CLE) | CLE) oe oe meee nce? sick (LE) 
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Table II-J-4: Actions taken as a result of Response Frames received in various states of the 
Link Layer Interface as perceived by DTEs 


(RT) {CAR) [€SS) 1(AX) 1085S) | CAX) (IH) | (IH) 
Is Is IR IR IR IR pc? | «pc? 
(fF) 18204) ~ |#2 - CF) / #20) (d)} dd} 


APPENDIX J: LINK LEVEL DTE ACTIONS | Lies 19 


SNA7X.25 DTE/DCE Interface 


Table II-J-4a: Actions taken as a result of Response Frames received in various states of the 
| Link Layer Interface as perceived by DTEs 


(RT) |CAR) |CSR) [CXR) FCSR) F CXR) 
IS IS IR IR IR IR 
Clipse.) C1) (#201) (1); #201) 


APPENDIX J: LINK LEVEL DTE ACTIONS II-J-20 


SNA/X.25 DTE/DCE Interface 


Table II-J-4b: Actions taken as a result of Response Frames received in various states of the 
Link Layer Interface as perceived by DTEs 
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| Table II-J-Ge: Actions taken as a result of Response Frames received in various states of the 
Link Layer Interface as perceived by DTEs 


| RESPONSE , 


ini — ree i eee ) (Le) ee sa pepe pepe ore? ote? sacks Ee sa ake 


Note 1 - Detection of the Idle Channel condition may be either ignored; or, if a flag 
sequence is not received within a period of time (Ti), considered as an event 
causing a change to the DISCONNECTED state (a) (see § 2.2.12.2). 


Note 2 - Upon correct receipt of a frame (containing an Nr that is higher than the last 
Nr received) acknowledging some previously transmitted I-frame(s), DTEs reset 
(stop) Reply Timer Tp and if additional unacknowledged I-frame(s) are still 
outstanding they restart Reply Timer Tp. 


Note 3 - Expirations of the Nested Time-out Function (Ft) are reported to a higher 
layer and the current state(s) of the Link Layer Interface maintained pending 
instructions from the higher layer. 


Note 4 - Illegal frames received are reported toa higher layer and the current 
state(s) of the Link Layer Interface maintained pending instructions from the 
higher layer. (FRMR?) 


Note 5 - To maintain DTE control, the 3705/X%.25 NPSI transmits a SABM command with 
‘P=1', creating a collision of like commands, and then transmits a UA response 
to the received SABM command. 


>Note 6 - DTEs not prepared to continue/resume normal link level operation transmit a 
UA response followed by a DISC command and enter the Disconnect Requested 
(DCRQD) state. 
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LINK LAYER ACTION CODE REFERENCE SUMMARY 
CAA) — Advance Transmit Window, Acknowledge Receipt and Forward 
CAD) — Advance Transmit Window and Discard Frame 
CAF) — Acknowledge Receipt and Forward 
CAL) — Assure Link 
CAR) — Advance Transmit Window and Resume Transmission 
CAS) — Advance Transmit Window and Suspend Transmission 
(AW) — Advance Transmit Window 
(AX) — Advance Transmit Window and Set Send Sequence 
(DF) — Discard Frame 
(DL) — Disconnect Link 
(IC) — Increment Count 
CIF} — Ignore Frame 
CIH) — Report Status/Condition 
CIL) — Initialize Link 
CLE) — Local Procedure Error 
(NS) — No Specific Action 
CRE) — Remote Procedure Error 
(RL) — Reset Link Level 
(RT) — Resume Transmission 
(SR) — Set Send Sequence and Resume Transmission 
(SS) — Set Send Sequence 
(ST) — Suspend Transmission 
(TR) — Time Reply 


(XR) — Advance Transmit Window, Set Send Sequence and Resume Transmission 
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K.0 APPENDIX K: ENHANCED LOGICAL LINK CONTROL — ELLC 


The formats and protocols described in this appendix are adaptations of Asynchronous 
Balanced Mode (CABM) formats defined for HDLC and the X.25 Link Access Procedure - 
Balanced (C(LAPB) elements of procedure expanded to include an adaptation of the 
checksum data integrity mechanism defined in IS-8073 (€COpen Systems Interconnection 
Transport Protocol Specification - ISO/TC-97/SC-6-N3240) dated September 1984. 


K.1 FUNCTIONAL OVERVIEW 


K.1.1 Architecture 


Architecture to meet SNA quality of service requirements in packet-switched data 
network environments: 


1. extends the Protocol Identifier defined for QLLC, in chapter 8.0, to allow 
Sra va of the ELLC protocol, at call set-up time, as an alternative to QLLC or 
_LLC; 


2. definition of a Connection_Type_Indicator (CTI) field within the Call_User_Data 
field of X.25 CALL_REQUEST packets to distinguish between initial connection 
requests and connection recovery requests for ELLC; 


3. use of the Connection_Identifier (CID) field in Call Set-up packets to carry 
Link_Connection_Identification information between adjacent link stations; 


4. definition of LPDU headers that include: 

° a two-byte address field; 

e an extended (two-byte) control field; 

© a two-byte checksum field; and, 

e the use of LPDU headers in the User_Data field of X.25 DATA packets and DATA 
packet sequences to perform sequenced transfer of BTUS between link stations 
in adjacent SNA nodes. 

5. the definition of recoverable call clearing, virtual circuit resetting and 


interface restarting cause codes together with link connection’ recovery 
procedures. 


K.1.2 Link Connection Service 


With a one-for-one correspondence between DLC.X25 link connections and X.25 virtual 
circuits, link connection services required for logical link control, to meet quality 
of service enhancement objectives in PSDN environments, are provided by adaptation of 
existing X.25 Packet Level call set-up and clearing procedures. 


K.1.3 Link Connection Identification 


Since a one-for-one correspondence exists between X.25 logical channels and LLC link 
stations, X.25 logical channel identifiers can be used by LLC to route DATA packets to 
the appropriate link station. DLC.X25 link connection identification requirements are 
satisfied by correlating X.25 Calling DTE Address, concatenated with a Connection 
Identifier carried in CALL REQUEST packets when parallel virtual calls are employed 
between DTEs, with X.25 logical channel identifiers. 
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K.1.3.1 Permanent Virtual Circuit Services 


The relationship between DLC.X25 link connections employing permanent virtual 
circuits and X.25 logical channel identifiers are fixed by bilateral agreement between 
communicating link stations; therefore, X.25 logical channel identifiers can suffice 
for both LLC routing and error recovery functions, in this environment. 


K.1.3.2 Switched Virtual Circuit ( Virtual Call } Services 


Since X.25 logical channel identifiers for switched virtual circuits are dynamically 
assigned at call set-up time, they suffice only for the LLC routing function; and, are 
correlated to the X.25 Calling DTE Address, concatenated with the Connection 
Identifier as required, for use in error. situations requiring re-connection 
procedures. 


K.1.4 Error Detection and Recovery 


LLC error detection and recovery requirements are satisfied by ELLC which, when. 
selected, provides mechanisms to detect, and procedures to attempt recovery from, the 
loss, duplication and/or corruption of LPDUS by underlying network services. ELLC 
incorporates sequence numbering and validity checking mechanisms, as well as circuit 
assurance procedures. 


K.1.4.1 Sequence Numbering 


ELLC formats and protocols provide for the sequenced (modulo 128) transfer of 
information LPDUs, together with LPDU acknowledgment and retransmission recovery 
procedures to guard against the loss or duplication of LPDUs, or both. 


K.1.4.2 Validity Checking 


ELLC also employs a checksum mechanism to detect LPDUs that have been corrupted by 
underlying network services and to insure the integrity of BTUs delivered to higher 
level using protocols. 


K.1.%.3 Circuit Assurance 


ELLC circuit assurance capability defines recoverable error conditions reported by 
PSDNs through CLEAR, RESET and RESTART packets, as well as procedures for ascertaining 
and performing actual circuit recoverability. 


K.2 SCOPE AND FIELD OF APPLICATION 


The Logical Link Control (LLC) procedure is described as the element used to enhance 
the quality of service exhibited to higher level SNA users by the underlying network 
services in supporting the transfer of information between adjacent SNA nodes in PSDN 
environments. 


The procedure uses the principles and terminology of the High Level Data Link Control 
tay procedures specified by the International Organization for Standardization 
SO). | 


The transmission facility is duplex. 
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Compatibility of operation with the I50 balanced class of procedure (Class BA, options 
1, 2, 8 and 12) is achieved using the provisions found in this specification. 


K,3 LINK PROTOCOL DATA UNIT STRUCTURE 


All transfers across ELLC link connections are in LLC Protocol Data Units C(LPDUs) 
conforming to one of the formats shown in Figure K-1 and contained in the User Data 
fieid of X.25 DATA packets or DATA packet sequences. 


3 


1 2 5 6 


ra 
A Cc xX Y 
16—-bits 16—-bits 2 Octets* 


Supervisory and Unnumbered Format 


Octet 1 3 4 


2 5 6 


A C xX Y 
16-bits 16-—bits 2 Octets* 


Information Format 
PDUCS = Protocol Data Unit Checking Sequence —- (Checksum) 
¥ an Octet is an &-bit byte. 


Figure K-11. LPDU Formats: Supervisory and Unnumbered versus Information 


I-Field 


I 
N-Octets* 


K.3.1 Address ( A ) Field 


The LPDU address is a two-octet (16-bit) field which has the format shown in Figure 
K-2. The A field is positioned as shown in Figure K-1 and coded as described in 
"Procedure for Addressing" on page II-K-13. 


NMNPNMDMMYNM NMMNMNNMNNDNNMAVNMNYNNMANNNNNMNNNAMNNNNNANNMNNNNN 


| Octet 1 | Octet 2 | 


where: 
ADDRESS - 18 reserved and set to zeroes; and 


is the LPDU command/response (C/R) indicator which is set to: 
"0" in command LPDUS; and, 
"1" In response LPDUs. 


x = 


Figure K-2. LPDU: Address Field Format 


K.3.2 Control ( C ) Field 


NMP PM PPP PMP PN PMN PDP PD NP PO PA PO 


2 The C field is two octets positioned as shown in Figure K-l. whose content is described 
2 in “LPDU Formats and State Variables" on page II-K-5. 
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K.3.3 Information ( I ) Field 


The I-field of LPDUs transmitted and received by link stations contain an SNA Path 
Information Unit (PIU) consisting of an integral number of octets (8-bit bytes). 


Note: LPDUs containing other than an integral number of octets may be ignored at the 
physical or link level. , 


See "LLC Protocol _Data_Unit_Reject ( LPDUR ) Response” on page II-K-9 and "List of LLC 
Parameters"™ on page II-K-20 with regard to the maximum information field length. 


K.3.% Protocol Data Unit Checking Sequence ( Pnucs )} Field 


The PDUCS field is two octets positioned as shown in Figure K-1 whose content is 
described in "Protocol. Data_Unit_Checking_Sequence ( PDUCS )" on page II-K-11l. 


K.3.5 Order of Transmission 


Address, control, sequence number, Protocol Data Unit Checking Sequence (PDUCS) and 
information octets are transmitted in ascending octet number order as indicated in 
Figure K-1 low order bit first. 


K.3.6 Invalid LPDUs 


LPDUs having fewer than forty-eight bits ( six octets ) are invalid. 


K.3.7 Link Channel States 


A itnk channel is defined as the means of transmission for one direction. 


K.3.7.1 Active State 


A link channel is in an active condition when the link station is actively 
transmitting an LPDU. 


K.3.7.2 Idle State 


A link channel is defined to be in an idle condition when the link station fails to 
receive an LPDU for a system specified period of time. 


K.4 ELEMENTS OF PROCEDURE 


The elements of procedure are defined in terms of actions that occur on receipt of 
commands or responses or the occurrence of events, at ELLC link stations. 


The elements of procedure specified here contain a selection of commands and responses 
relevant to the ELLC link connection and system configuration described in "Scope and 
Field of Application” on page II-K-2. 


A procedure derived from these elements of procedure is described in "Description of 
the Procedure" on page II-K-13. Together "LPDU Formats and State Variables” on page 
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II-K-5 and "Elements of Procedure" form the general requirements for proper management 
of link connections between ELLC link stations in adjacent nodes. 


K.4¢.1 LPDU Formats and State Variables 


The various LPDU formats and link station state variables used for ELLC are described 
under "Control ¢€ C ) Field Formats" and "Control Field Parameters." 


K.4.1.1 Control ( C ) Field Formats 

The C field contains a command or a response, and sequence numbers, where applicable. 
Three LPDU C-field formats as shown in Figure K-3 are defined for use: 

° IPDUs - to perform sequenced information transfers; 


e SPDUs - to perform numbered supervisory functions; and 
@ UPDUs - to perform unnumbered control functions. 


Control field bits 8765432 1 8 7 6 5 43, 2 1 
[information Grou) [ine [P| ssid 
wr per [ex m[x[sstola 
oe Ce 


LNs = transmitter send sequence number (bit 2 = low order bit). 
LNr = transmitter receive sequence number (bit 2 = low order bit). 
S = supervisory function bit. 
M = modifier function bit. 
P/F = poll (P) bit in command frames or final (CF) bit in response 


frames (1 = Poll/Final). 


Figure K-3. LPDU: Control Field Formats 


Information_Protocol Data _Unit - IPDU: used to perform sequenced information 
transfers. Except as otherwise specified Ci.e., LPDUR, LTEST, LXID) it is the only 
LPDU that may contain an information field. The functions of LNs, LNr and P/F are 
independent; i.e., each IPDU has an LNs, and an LNr which may or may not acknowledge 
a tee IPDUS received by the ELLC link station transmitting the LNr, anda P/F 
it. 

Supervisory Protocol Data_Unit - SPDU: used to perform link supervisory control 
functions such as acknowledging IPDUs, requesting retransmission of IPDUs, and 
requesting temporary suspension of IPDU transmission. 


Unnumbered_Protocol_Data_Unit - UPDU: used to provide additional link control 
functions. This format contains no sequence numbers. 


K.4.1.2 Control Field Parameters 

Parameters associated with the control field formats include a modulus (m), LPDU 
variables and sequence numbers. 

Modulus - ‘'m': IPDUs are sequentialiy numbered and may have the value 'LNs=0' through 
"LNs=m minus one’ (where 'm' is the modulus of the sequence numbers). '‘'m’ is equal to 
"128" and the sequence numbers cycle through the entire range '0' to '127", inclusive. 


State Variables and Sequence Numbers: 


1. Link Send State Variable ( LVs ) 
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LVs denotes the sequence number of the next in-sequence IPDU to be transferred 
across the link connection. LVs can take on the value '0' through 'm minus one’. 
The value of LVs is incremented by one with each successive IPDU transferred but 
at originating link stations cannot exceed LNr of the last received IPDU or SPDU 
by more than the maximum permissible number of outstanding IPDUs (Lk). The value 
of ae is defined in "Maximum Number of Outstanding IPDUs - ( Lk )" on page 
II-K-23. | 


2. Link Send Sequence Number ( LNs ) 


Only IPDUsS contain LNs, the send sequence number of transferred PDUs. Prior to 
transferring an in~sequence IPDU, the value of LNs is set equal to the value of LVs 
at the originating link station. 


3. Link Receive State Variable ( LVr ) 


LVr denotes the sequence number of the next in-sequence IPDU to be received at 
destination link stations. LVr can take on the values '0' through 'm minus one’. 
The value of LVr is tneremented by one upon receipt of each error free, 
in-sequence (with an LNs that is equal to the current value of LVr at the receiving 
Link station) IPDU. 


G4. Link Receive Sequence Number ( LNr ) 


All IPDUs and SPDUs contain LNr, the expected sequence number of the next received 

IPDU. Prior to transmitting an IPDU or SPDU, LNr is set equal to the current value 

of LVr at the originating link station. LNr indicates that the link station 

ane LNr has correctly received all IPDUs numbered up to and including 
r minus ; 


K.4.1.3 Functions of the Poll/Final Bit 


The poll/final (P/F) bit serves a function in both command LPDUs and response LPDUs. 
In command LPDUs the 'P/F*' bit is referred to as the Poll (P) bit. In response LPDUs 
it is referred to as the Final (F) bit. 


Procedures for use of the 'P/F' bit are described in "Procedure for Use of the P/F Bit" 
on page II-K-14. 


K.4.2 Link Commands and Responses 


Command and response LPDUs transmitted and received by link stations in adjacent nodes 
are depicted in Figure K-4 and are described in "LLC_Information € LI ) Command" on 
page II-K-?7 through "LLC_Test € LTEST ) Command and Response" on page II-K-10. 
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Second Octet First Octet 
Bit Positions 
87656432. 1 8 7 6 


Cc 
M 
D 
(S) 
LRR 
N 
oO LRNR LNr 
t . 
LDISC 


LXID LXID 
LTEST 


3 Disconnect 

Disconnected Mode 
Protocol Data Unit Reject 
Information 

Reject 

Receive Not Ready 

Receive Ready 

Set Asynchronous Balanced Mode — Extended 
Unnumbered Acknowledgment 
Exchange Identification 
Test 


Link stations transmit all Supervisory and Unnumbered command 
LPDUs with ‘'P=1"'. 


Figure K-4. LPDU: Commands and Responses 


K.4.2.1 LLC_Information ( LI ) Command 


LI commands are used to transfer sequentially numbered PDUs that contain information 
fields, across link connections between link stations in adjacent nodes. 


K.4.2.2 LLC _Receive_Ready ( LRR ) Command and Response 


LRR command/response SPDUs are used by link stations to: 

1. indicate that they are prepared to receive IPDUs 

2. acknowledge previously received IPDUs numbered up to and including 'LNr minus l1'. 
LRR command/response SPDUs may be used to clear busy conditions initiated by the prior 
transmission of LRNR command/response SPDUs. LRR command SPDUs with 'P=1" may be used 


by link stations to solicit the status of the communicating link station in the 
adjacent node. 
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K.4.2.3 LLC_Reject ( LREJ ) Command and Response 


LREJ command/response SPDUs are used by link stations to request retransmission of 
IPDUs starting with the IJPDU numbered LNr. IPDUs numbered 'LNr minus 1’ and below are 
acknowledged. Additional IPDUs pending initial transmission may be transmitted 
following the retransmitted IPDU(s). 


Only one LREJ exception condition for a given direction of information transfer may be 
established at any time. LREJ exception conditions are cleared (reset) upon receipt 
of an IPDU with an LNs equal to the LNr contained in the LREJ SPDU. 


K.4.2.4 LLC_Receive_Not_ Ready ( LRNR ) Command and Response 


LRNR command/response SPDUs are used by link stations to indicate busy conditions; 
1.e@., temporary inability to accept additional IPDUs. IPDUsS numbered up to and 
including 'LNr-1" are acknowledged. IPDU LNr and subsequent IPDUs reccived, if any, 
are not acknowledged; the acceptance status of these IPDUsS is indicated in subsequent 
exchanges. 


Indication that a busy condition at a link station has cleared 1s communicated to the 
Coo cena link station in the adjacent node by the transmission of an LUA, LRR, 
EJ or LSABME. | 


LRNR command SPDUs with the 'P=1' may be used by link stations to solicit the status of 
the communicating link station in adjacent nodes. | 


K.4.2.5 LLC_Set_Asynchrenous_Balanced_Mode_Extended ( LSABME. ) Command 


LSABME commands are used to initialize/re-initialize both directions of transmission 
across the link connection between link stations in adjacent nodes. The DLCO.xX25.CM 
initiates transmission of the LSABME command upon receipt of a "CONTACT_ALS" from 
SNA.PU. No information field is permitted with this command. Link stations in 
adjacent nodes confirm acceptance of LSABME commands by transferring an LUA response 
across the link connection at the earliest opportunity. Upon acceptance of an LSABME 
command, the communicating link station in the adjacent node sets both its send and 
receive state variables (LVs and LVr) equal to '0" and assumes the link asynchronous 
balanced mode - extended. When the LUA response is correctly received, the initiating 
link station also assumes the link asynchronous balanced mode - extended and sets its 
send and receive state variables (LVs and LVr) equal to '0". LSABME commands are 
always transferred with ‘'P=1' 


Previously transferred IPDUs that are unacknowledged when the LSABME command is 
initiated and executed remain unacknowledged (see "Waiting for Acknowledgment" under 
"Procedures for Information Transfer" on page II-K-16). Any transmit buffers that are 
unacknowledged or pending initial transmission are purged from the link station queue 
and returned to the upper level user function. 


K.4.2.6 LLCO Disconnect ( LDISC ) Command 


LDISC commands are used by link stations to terminate the operational mode previously 
set. LDISC informs the communicating link station in the adjacent node that the link 
station 1s temporarily suspending operation. 


No information field is permitted with LDISC commands. Prior to executing LDISC 
commands, receiving link stations confirm acceptance by transmitting an LUA response. 
Transmitting link stations enter the link disconnected phase upon receipt of the 
acknowledging LUA response. LDISC command LPDUs are always transmitted with 'P=1'. 


Previously transmitted IPDUs that are unacknowledged when the LDISC command is 


executed remain unacknowledged (see Waiting for Acknowledgment under "Procedures for 
Information Transfer" on page II-K-16). 
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K.4.2.7 LLC_Unnumbered_Acknonledgment ( LUA ) Response 


LUA responses are used by originating link stations to acknowledge receipt and 
indicate acceptance of LSABME and LDISC commands. Receiving link stations transfer an 
LUA response before executing the received UPDU command. The LUA response 15 
transferred with 'F=1" when 'P=1' in the received UPDU command. No information field 
is permitted with LUA responses. 


K.4.2.8 LLC_Disconnected_Mode ( LDM ) Response 


LDM responses are used to report a status where the originating link station is 
logically disconnected, and is in the LLC disconnected phase. The LDM response may be 
sent in response to a received LSABME command, to inform the adjacent node link 
station that the originating link station is still in the LLC disconnected phase and 
cannot execute the LSABME command. No information field 1s permitted with the LDM 
response. 


Link stations in the link disconnected phase monitor received commands and: 


1. react to LSABME and LDISC commands as described in "Link Disconnected Phase" on 
page II-K-15; and, 


2. transfer an LDM response with 'F=1' to any other UPDU command received with "P=1". 


K.4.2.9 LLC Protocol Data_Unit_Reject ( LPDUR ) Response 


LPDUR responses are used by link stations to report error conditions that are not 
recoverable by retransmission of the identical LPDU to the adjacent link station; 


1.e@., one of the following conditions, resulting from the otherwise error free receipt 
of an LPDU with: : 


1. a LPDU command or response that is invalid or not implemented; 

2. an information field that exceeds the maximum permissible length; 
3. an invalid LNr; or, 
: 


- an Information field which is not permitted or an SPDU or UPDU of incorrect 
length. 


An invalid LNr is one that points to an IPDU that has been previously transmitted and 
acknowledged or to an IPDU that has not been transmitted and 1s not the next sequential 
IPDU pending transmission. 


An information field which immediately follows the control field, and consists of 5 
octets, 1s returned with the LPDUR response. This format 1s shown in Figure K-5. 
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I-field bits 11 2 2 2 3.63 3 3 3 3 3 3 3 4 
LS SS Ss 67 —-=-- 3 4&4 5-—--=— 1] 2 3 4 5 6 7 8 9 0 
Rejyected LPDU C | 
LVs LVr 7 0 Z Y xX 
Control Field R 


~ Rejected LPDU control field is the control field of the received LPDU that 
caused the PDU reject condition. 

- LVs is the current value of LVs at the link station reporting the rejec- 
tion condition (bit 23 = low order bit). | 

- LVr ts the current value of LVr at the link station reporting the rejec- 
tion condition Cbit 31 = low order bit). | 

~ 'W=1" tndicates that the control field received and returned in bits 1 
through 16 was considered invalid or not implemented. 

- 'X=1' indicates that the control tield received and returned in bits 1 
through 16 was considered invalid because the LPDU contained an informa- 
tion field which is not permitted or 1s an SPDU or UPDU with incorrect 
length. 'W=1" is required in conjunction with this bit. 

- "Y=1' indicates that the information field received exceeded the maximum 
established capacity of the link station reporting the condition. 

~ 'Z=1' indicates that the control field received and returned in bits 1 
through 16 contained an invalid LNr. 

- C/R - Bit 32 is set to: 

"1" if the rejected LPDU was a response; or, 
"0" if the rejected LPDU was a command. 


Figure K-5. LPDUR: Information Field Format 


K.4.2.10 LLC_Exchange_Identification ( LXID )} Command and Response 


LXID commands are used by ELLC link stations to initiate exchanges of identification 
information with link stations at the adjacent SNA nodes. 


K.%4.2.11 LLC_Test (€( LTEST ) Command and Response 


LTEST commands are used by ELLC link stations to initiate tests of link connections 
and solicit an LTEST response from ELLC link stations in adjacent nodes. 


K.4.3 Exception Condition Reporting and Recovery 


Procedures to effect recovery following the detection/occurrence of exception 
conditions on the connection between link stations in adjacent SNA nodes are described 
in "Busy Condition” through "LPDU Rejection Condition" on page II-K-l2. Exception 
conditions described include situations that may occur as the result of underlying 
network malfunctions or abnormal operational situations. 


K.4.3.1 Busy Condition 


A busy condition results when an ELLC link station is temporarily unable to continue 
receiving IPDUs due to internal constraints (Ce.g., receive buffering limitations). 
Notification of the busy condition is conveyed to the link station in the adjacent 
node by transferring an LRNR across the link connection. IPDUs pending transmission 
may be transmitted by link stations experiencing a busy condition, either prior to, or 
following, transmission of the LRNR. Recovery from a link station busy condition is 
indicated to link stations in adjacent nodes as described in "LLC_Receive_Not_Ready ( 
LRNR ) Command and Response" on page II-K-8. 
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K.4.3.2 LNS Sequence Error 


A sequence exception condition results when an error-free (no PDUCS error) IPDU with 
an LNs that 1s not equal to the current value of LVr at the receiving link station is 
received. Receiving link stations do not acknowledge Cincrement their LVr) IPDUs that 
result in sequence exception conditions. 


The information field of all IPDUsS received with an LNs that is not equal to the 
current value of LVr at the receiving link station is discarded. 


ELLC link stations that receive one or more IPDUs having sequence errors but otherwise 
error-free accept the control information contained in the LNr field and the 'P* bit 
to perform link control functions (e.g., to receive acknowledgment of previously 
transmitted IPDUs and to cause the link station to respond ('P=1"')). =Therefore, 
retransmitted IPDUs may contain an LNr field and '‘'P' bit that are updated, and 
therefore different from, those contained tn the IPDUCS) originally transmitted. 


K.4.3.3 LLC REJECT Recovery 


LREJ commands and responses are transferred by link stations to initiate exception 
recovery Cretransmission) following detection of sequence errors. 


Only one "sent LREJ™ exception condition for a link station is established at a time. 
A "sent LREJ" exception condition is cleared when the requested IPDU is received; or, 
when a link set-up or disconnection procedure as described in "Link Resetting 
Procedures" under "Procedures for Information Transfer™ on page IJI-K-16 is performed. 


Link stations receiving LREJ initiate sequential Cre-)transmission of IPDUs starting 
as the one indicated by the LNr contained in the received LREJ SPDU,-if possible (see 
-K.6.5.4). 


K.4.3.4 Time-out Recovery 


If, due to a transmission error, a link station does not receive (or receives and 
discards) a single IPDU or the last IPDU in a sequence of IPDUs, it cannot detect an 
out-of-sequence exception condition and will, therefore, fail to transmit an LREJ. 
Link stations shall, following completion of a system specified time-out period (see 
"List of LLC Parameters” on page II-K-20) take appropriate recovery action to 
determine at which IPDU retransmission must begin. 


Link stations use the lost reply protection mechanism, described in "Lost Reply 


Protection” on page II-K-14, after a system specified time-out period (see "List of 
LLC Parameters" on page II-K-20) to determine at which IPDU to begin retransmission. 


K.4.3.5 Protocol Data_Unit_Checking_Sequence ( PDUCS ) 
The purpose of the PDUCS is to detect LPDUs that have been corrupted by the underlying 
network service. 


When an LPDU is to be transmitted the sending link station must generate a PDUCS for 
the LPDU and store it in the PDUCS parameter in the LPDU header. 


1. PDUCS € Checksum ) Generation Procedure 
a. Set up the complete LPDU, including the header and user data (if any). The 
header must include the PDUCS parameter. The value field of the PDUCS 
parameter must be set to zero at this point. 
b. Initialize two variables (called C® and C!) to zero. 
c. For each octet of the LPDU, including the header and the user data Cif any), 
add the octet value to C®, and then add the value of C° to C!. Octets are 


processed sequentially, starting with the first octet and proceeding through 
the LPDU. Addition is performed modulo 256. 
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d. Calculate the value field of the PDUCS parameter as follows: 


e Let the length of the LPDU, ji.e., the number of times the above operation 
was repeated be 'L'; 


° Let the first octet of the PDUCS value, i.e., the one at offset 'i' ( where 
"7=5' 0, be called ‘'X'; 


° Let the second octet, at offset 'j* ( where 'j=4' ), be called 'Y’. (Where 
the first byte of the LPDU is considered to be at offset 'l1'). 


Then: 


CCCL - 1) x C°) - C!) modulo 256; and, 
Y = (CCL - jd ® C- C°)) + C1) modulo 256 


e. Place the computed values of '"X' and 'Y’ in the appropriate octets of the 
LPDU. | 


Note: An implementation may use one's complement arithmetic as 
alternative to modulo 256 arithmetic. However, if either of the PDUCS selon 
*X' and 'Y' has the value minus zero (ji.e., x'FF"') then it must be converted to 
plus zero (1.e., x'00") before being stored. 


2. PbdUCS © Checksum ) Validation Procedure 


When an LPDU is received it is verified to ensure that it has been received 
correctly. This is done by computing the PDUCS, using the same algorithm by which 
it was generated. The nature of the PDUCS algorithm is such that tt is not 
necessary to compare explicitly the stored PDUCS octets. The procedure described 
below may be used to verify that an LPDU has been correctly received. 


a. Initialize two variables (called C® and C!) to zero. 


b. For each octet in the received LPDU, add the value of the octet to C® and then 
add the value of C® to C?, starting with the first octet and proceeding 
sequentially through the LPDU. All addition is performed modulo 256. 


c. When all octets have been sequentially processed, the values of C® and C? 
should be zero. If either or both of them is non-zero, the LPDU has been 
received incorrectly and the verification has failed. Otherwise, the LPDU has 
been received correctly and the LPDU is processed normally. 


Note: An implementation may use one's complement arithmetic as_~— an 
alternative to modulo 256 arithmetic. In this case, if either C°® or C! has the 
value minus zero (Ci.e., x'"FF') it is regarded as though it was plus zero 
Ci.e., x'00'"). 


If a PDUCS verification failure occurs, the received LPDU is discarded and no 
actions 1s taken by any link station at the receiving DTE as a result of that LPDU. 


K.4.3.6 LPDU Rejection Condition 


An LPDU rejection condition may be established upon receipt of an error-free LPDU that 
contains an invalid command/response in the C field, an invalid LPDU format; an 
invalid tNr or an information field that exceeds the maximum information field length 
that can be accommodated. 


Receiving ELLC link stations report LPDU rejection conditions to the communicating 
link station in the adjacent node by transferring an LPDUR response across the link 
connection. ELLC link stations that receive an LPDUR response are responsible for 
resolving the rejection condition by initiating etther a link resetting or link 
disconnection procedure; or, by causing a clearing or resetting of the underlying 
virtual circuit. After transmitting an LPDUR response, ELLC link stations maintain 
the LPDU rejection condition until the link is reset by the communicating link station 
in the adjacent node. IPDUs received by ELLC link stations in the LPDU rejection 
condition are discarded, except for the 'P* bit indication (LNr is tgnored). The 
LPDUR response may be repeated at each opportunity until recovery is effected by the 
communicating link station in the adjacent node, or until internal recovery 15s 
initiated locally. 
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K.4.3.7 Recoverable Packet Level Error Conditions 


Network initiated virtual circuit terminations (clears) and re-synchronizations 
(resets), as well as interface re-initializations (restarts) considered to be 
potentially recoverable at the logical link control level include those resulting from 
the receipt of indication packets with the Cause Codes shown in Figure K-6, Figure K-7 
and Figure K-8. 


CLEARING CAUSE 


Number busy 

Out of order 

Access Barred 

Remote Procedure Error 
Local procedure error 


> b> fae 
1S 0A Oe 


Network congestion 
Not obtainable 
RPOA out of order 


Ne 
m= CA 


Figure K-6: Recoverable CLEARING Cause Codes 


RESETTING CAUSE 


Out of order 

Remote procedure error 
Local procedure error 
Network congestion 
Remote DTE operational 
Network operational 
Incompatible destination 


Figure K-7. Recoverable RESETTING Cause Codes 


RESTARTING CAUSE 


Local procedure error 


Network congestion 
Network operational 


Figure K-8. Recoverable RESTARTING Cause Codes 


K.5 DESCRIPTION OF THE PROCEDURE 


The charts in "LINK STATION STATES AND ACTIONS” on page II-K-25 detail the actions 
taken, LPDUs transferred and state transitions made by ELLC link stations as a result 
of stimuli that can occur in various states of the link connection. 


K.5.1 Procedure for Addressing 


LPDUs are transferred with the address field set to indicate their command/response 
content. 
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K.5.2 Procedure for Use of the P/F Bit 


Upon receipt of any command LPDU with ‘'P=1", ELLC link stations transfer an 
appropriate response LPDU with 'F=1' across the link connection at the first respond 
opportunity Ce.g., immediately following the LPDU currently being transmitted, if 
any). Appropriate responses include: 


1. an LUA or LDM response to received LSABME and LDISC commands; 

2. an LPDUR, LREJ, LRNR or LRR response to received IPDU commands; and, — 

3. an LXID or LTEST response to received LXID or LTEST commands, respectively; 

4. an LPDUR, LRNR or LRR response to received SPDU commands. 

The 'P*® bit is also used in conjunction with timer recovery conditions as described in 
"Waiting for Acknowledgement™ on page II-K-18 and may be used as a request for 


acknowledgment on IPDUsS and invitation to transmit, by the upper level user(s), in 
application environments that exhibit half-duplex characteristics. 


K.6 LOST REFLY PROTECTION 


ELLC link stations provide a time-out function to protect against dead-lock conditions 
caused by loss of responses from communicating Link stations in the adjacent node due 
to transmission errors. An LLC Reply Timer, LT1, may be started upon transmission of 
IPDUs or SPDU commands, or both, during the information transfer phase. Link Reply 
Ubu ne 1s also used as described in "Link Set-up” and "Link Disconnection" on 
page IJI-K-15. 


If Link Reply Timer, LT1, expires prior to receipt of an appropriate response from the 
communicating link station in the adjacent node, ELLC link stations initiate action to 
recover the link connection. ELLC link stations transfer an appropriate command SPDU 
and restart Link Reply Timer, LT1. If Link Reply Timer, LT1, expires prior to receipt 
Rta eeege arr es response with '‘'F=1"' LN2 times, appropriate recovery action is 
initiated. 


K.6.1 Procedures for Link Set-Up and Disconnection 


K.6.1.1 Link Set-up 


ELLC link stations wishing to set-up the link connection transfer an LSABME command 
with "P=1" and start Link Reply Timer, LT1 (Csee "LLC _Time-Out_Function - € LFt 3" on 
page IJI-K-20. Upon receipt of an LUA response with "F=1' from the link station in the 
adjacent node, the initiating ELLC link station sets both LVs and LVr equal to '0' and 
stops link Reply Timer, LTl. 


Upon receipt of an LSABME command, receiving ELLC link stations prepared to receive 
IPDUs return an LUA response and set both LVs and LVr equal to '0'. ELLC link stations 
that, for seme reason; are unable or do not desire to enter the information transfer 
phase, return an LDM response to received LSABME commands. 


Upon receipt of an LDM response with 'F=1' indicating that the adjacent link station 
cannot accept activation of the link connection, the condition is reported to the 
upper level user and no further action is taken by logical link control. 


Upon expiration of Link Reply Timer, LT1, prior to receipt of an appropriate response 
with '‘'F=1"', ELLC link stations perform the retransmission procedure described in 
"LLC _Time-Out_Function - ( LFt )" on page II-K-20 before declaring the link connection 
to be inoperative and reporting the condition to a higher level of SNA. 
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K.6.1.2 Information Transfer Phase 


ELLC link stations, having transferred an LUA response to a received LSABME command or 
having received an LUA response to a transmitted LSABME command, accept and transmit 
IPDUs and SPDUs in accordance with the procedures described in “Procedures for 
Information Transfer” on page II-K-16. 


Upon receipt of an LSABME command, an LUA response or an LDM response with 'F=0', while 
in the information transfer phase, ELLC link stations conform to the resetting 
procedure described in "Link Resetting Procedures” on page II-K-18. 


K.6.2 Link Disconnection 


During the information transfer phase ELLC link stations, wishing to terminate the 
link connection, transfer an LDISC command with 'P=1' across the link connection and 
start Link Reply Timer, LT1, (see "LLC_Time-Out_Function —- (€ LFt 2" on page II-K-20). 


Upon receipt of a LDISC command, receiving ELLC link stations return an LUA or LDM 
response and enter the Link disconnected phase. 


Upon receipt of an LUA or LDM response with 'F=1!' from the communicating link station 
in the adjacent node, initiating ELLC link stations stop Link Reply Timer, LTl. 


Upon expiration of Link Reply Timer, LTl, prior to receipt of an appropriate response 
with ‘F=1", ELLC link stations perform the retransmission procedure described in 
"LLC Time-Out_Function - ( LFt )™ on page II-K-20 before declaring the link connection 
to be inoperative and reporting a failure to the higher levels of SNA. 


K.6.2.1 Link Disconnected Phase 


ELLC link stations, having received an LDISC command and returned an LUA response, or 
having received an LUA response to a transmitted LDISC command, enter the link 
disconnected phase. 


ELLC link stations, in the link disconnected phase, may initiate link set-up. While 
in the link disconnected phase, ELLC link stations react to the receipt of LSABME 
commands as described in "Link Set-up" on page II-K-14 and transfer an LDM response to 
received LDISC commands. 


Upon receipt of any command Cother than LSABME) with '"P=1', receiving ELLC link 
stations transfer an LDM response with 'F=1". 


Other LPDUs are ignored by receiving ELLC link stations while in the link disconnected 
phase. 


K.6.2.2 Collision of UPDU Commands 


UPDU command collision situations are resolved in the following manner. 


Like Commands: When the sent and received UPDU commands are the same, both ELLC link 
stations transfer.an appropriate UPDU response at the earliest possible opportunity. 
ELLC link stations place the associated link connection in the indicated state upon 
receipt of the appropriate UPDU response. 


Unlike Commands: When the sent and received UPDU commands, other than LXID and LTEST, 
are different ELLC link stations place the associated Link connection in the 
LINK_CLOSED state and transfer an LDM response at the earliest possible opportunity. 
When the sent and received UPDU commands are LXID or LTEST, ELLC link stations 
transfer the appropriate LTEST and LXID response, respectively, when available. 
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K.6.3 Procedures for Information Transfer 


These procedures apply to the transmission of IPDUs in each direction of transmission 
during the link information transfer phase. 


In the following text, "number one higher™ is in reference to a continuously repeated 
sequence series, i.e., '127"' is one higher than '126' and '0' is one higher than '127' 
for modulo one hundred twenty eight series. 


K.6.3.1 Sending IPDUS 


ELLC link stations having IPDUs to transfer Ci.e., IPDUS not already transferred, or 
having to be retransmitted as described in "Receiving Reject” on page IJI-K-17 or 
"Waiting for Acknowledgement" on page II-K-18, transfer them with an LNs equal to the 
current value of that link stations LVs, and an LNr equal to the current value of the 
link stations LVr. Upon completion of transmission of each successive IPDU, ELLC link 
stations increment their LVs by one (1) and start Link Reply Timer, LT1, if it is not 
already running. 


When the value of LVs, at an ELLC link station, is equal to the last value of LNr 
received from the communicating link station in the adjacent node plus 'Lk’ (where 
"Lk' as the maximum permissible number of outstanding IPDUS allowed (see "Maximum 
Number of Outstanding IPDUs - € Lk )” on page II-K-23), that ELLC link stations does 
not transfer any new IPDUs, but may retransmit IPDUS as described in "Receiving 
Reject" on page II-K-17 or "Waiting for Acknowledgement" on page JI-K-18. 


Note: To ensure the integrity of information transfer, ELLC link stations do not 
transfer any IPDUs when the link stations LVS is equal to the last value of LNr 
received from the link station in the adjacent node plus '127'. 


ELLC link stations in the busy condition may continue to transfer IPDUs, provided the 
communicating link station in the adjacent node is not also ina busy condition. ELLC 
link stations in the link rejection condition, do not transfer IPDUs. 


K.6.3.2 Receiving IPDUS 


ELLC link stations not in the busy condition accept the I-field of in sequence IPDUs 
CIPDUs with an LNs equal to the current value of the link stations LVr) received with 
the correct PDUCS, increment the value of the link stations LVr by one and acknowledge 
receipt of the IPDUC(s) by transferring: 


° the next sequential IPDU to be transferred, if it is available, or an LRR response 
SPDU with LNr equal to the current value of its LVr; or, 


e an LRR response SPDU response with LNr equal to the current value of its LVr, if no 
IPDU is available to transfer. 


ELLC link stations may ignore the information field contained in IPDUS receive while 
they are in a. busy condition. 


Note: ELLC link stations treat IPDUs with zero length information fields the same as 
any other IPDU at the link station. 


K.6.3.3 Receipt of Incorrect LPDUs 


ELLC link stations ignore LPDUs received with an incorrect PDUCS and cause a clearing 
or resetting of the underlying virtual call or permanent virtual circuit, 
respectively, upon receipt of LPDUsS with invalid formats (see "Invalid LPDUs" on page 
II-K-4). 


ELLC link stations receiving IPDUs with the correct PDUCS, but with an incorrect LNs 
Ci.e., one that 1s not equal to the current value of LVr at the receiving link station) 
discard the I-field and transfer an LREJ response with an LNr one higher than the LNs 
contained in the last correctly received IPDU. Then they discard the I-field, but use 
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the LNr and 'P* bit indications of all IPDUs received with an LNs that is not equal to 
the current value of LVr at the receiving ELLC link station. Upon receipt of the 
expected IPDU Ci.e., one with an LNs equal to the current value of LVr), receiving 
ELLC link stations acknowledge the IPDU as described in "Receiving IPDUs”" on page 
II-K-16. 


K.6.3.4 Receiving AcknoNledgement 


ELLC link stations, even in a busy condition, consider the LNr contained in correctly 
received IPDUs or SPDUs CLRR, LRNR and LREJ) as acknowledgment for all IPDUs 
transferred with an LNs up to and including '"LNr minus 1'. ELLC link stations reset 
Link Reply Timer, LT1, upon correct receipt of an IPDU or SPDU that actually 
acknowledges some previously transferred IPDU(s) Ci.e., an LPDU with an LNr higher 
than the value of the last LNr received); or, upon receipt of an SPDU with. 'F=1'. 


If Link Reply Timer, LT1, has been reset with IPDUCsS) still unacknowledged, ELLC link 
stations restart Link Reply Timer, LT1. If Link Reply Timer, LT1, expires prior to 
receipt of an acknowledgment, ELLC link stations follow the retransmission procedure 
described itn "Receiving Reject" and "Waiting for Acknowledgement" on page II-K-18 with 
respect to the unacknowledged IPDU(s). 


K.6.3.5 Receiving Reject 


Upon receipt of an LREJ SPDU, receiving ELLC link stations, supporting LPDU 
retransmission recovery (see §-K.6.5.4), set LVs equal to the LNr contained in the 
received LREJ, then transfer the corresponding IPDU when it is available or retransmit 
it; otherwise, they cause a clearing or resetting the the virtual circuit. 


ELLC link stations conform to the following with respect to the re-transmission of 
IPDUs: 


1. An ELLC link station that is transmitting a SPDU or an UPDU when it receives a 
LREJ, will complete the transmission in progress before commencing transmission of 
the requested IPDU. 


2. An ELLC link station that is transmitting an IPDU when an LREJ 1s received, may 
abort transmission of the IPDU and commence transmission of the requested IPDU 
immediately after abortion. 


3. An ELLC link station that is not transmitting any LPDU when an LREJ is received, 
will commence transmission of the requested IPDU immediately. 


Other unacknowledged IPDUs already transferred, following the one indicated in the 
LREJ, are retransmitted following retransmission of the requested IPDU. 


If the LREJ was received as a command with 'P=1"', receiving ELLC link stations 
transfer an LRR or LRNR response with 'F=L' prior to transmitting or retransmitting 
the corresponding IPDU. 


K.6.3.6 Receiving LRNR 


Upon receipt of an LRNR command or response SPDU, ELLC link stations may start timer 
LTIn if it is not running. If timer LTn then expires prior to the receipt of a LUA, 
LRR, LREJ or LSABME from the communicating link station in the adjacent node, ELLC 
link stations transmit an appropriate SPDU command with P=1 and may perform the 
retransmission procedure described under "LLC _Time-Out_Function - (€ LFt 2" on page 
II-K-20 before declaring the link connection to be inoperative and reporting the 
condition to upper level user(s). 
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K.6.3.7 Link Station Busy Condition 


ELLC link stations experiercing a busy condition transfer an LRNR command or response 
at the earliest opportunity. While in the busy condition, ELLC link stations accept 
and process SPDUs and respond LRNR with 'F=1' to IPDUs and SPDU commands received with 
"P=1'. To clear a busy condition, ELLC link stations transfer either LREJ commands or 
responses or  LRR commands or responses with LNr set to the current value of LVr, 
depending on whether or not information fields of correctly received IPDUS were 
discarded. 


K.6.3.8 Waiting for Acknowledgement 


Originating ELLC link stations maintain an internal retransmission count (CY) which is 
set equal to '0' upon receipt of an LUA or LRNR, or upon correct receipt of an IPDU or 
an SPDU with an LNr higher than the last LNr received from the communicating link 
station in the adjacent node (actually acknowledging some IPDU(s)). 


If Link Reply Timer, LT1, expires, ELLC link stations enter or Cre-Jenter the timer 
recovery condition, increment ‘Y* by one (1) and set an internal variable (X) to the 
current value of LVs. | 


ELLC link stations restart Link Reply Timer, LT1, set LVS equal to the value of the 
last iNr received from the communicating link station in the adjacent node and 
transfer an appropriate SPDU command with 'P=1'. 


Timer recovery conditions are cleared upon receipt of a valid SPDU response with 
‘r= ' | 


Upon correct receipt of a SPDU response with "F=1" and an LNr within the range from the 
current value of LVs to ‘'X' included, ELLC link stations reset the timer recovery 
conditison and set LVs equal to the value of LNr in the received SPDU. 


Upon correct receipt of an SPDU with ‘F=0" and with an tNr within the range from the 
current value of LVs to 'X'" included, ELLC link stations do not reset the timer 
recovery condition. The received LNr may be used to update LVs. 


When ‘*Y’ is equal to LN2, ELLC link stations initiate a resetting procedure as 
described in "LLC Rejection Conditions” on page II-K-19 The value of LN2 1s a system 
parameter (see "Maximum Number of LPDU Transmissions ~— ( LN2 )" on page II-K-22). 


K.6.3.9 Link Resetting Procedures 


The resetting procedures described here are used, only on link connections perceived 
by the ELLC link station to be tin the information transfer phase, to (red-initialize 
both directions of information transfer. 


1. Local Reset 


ELLC link stations indicate a resetting of the link by transferring an LSABME 
command LPDU across the link connection. Upon receipt of an LSABME command, ELLC 
link stations prepared to resume normal operation of the link, return an LUA 
response at the earliest opportunity, and set LVs and LVr equal to '0'. This also 
clears link station busy conditions, if present. Prior to initiating this link 
resetting procedure, ELLC link stations may initiate a link disconnection 
procedure as described in "Remote Reset" below. 


2. Remote Reset 


Under certain rejection conditions listed in "LLC Rejection Conditions” on page 
TI-K-19, ELLC link stations may request the adjacent link station to reset the 
link by transferring an LPDUR response. 


After transmitting an LPDUR response, originating ELLC link stations enter the 
link rejection condition. The link rejection condition is cleared when the ELLC 
link station receives an LSABME or an LDISC command or an LDM response from the 
communicating link station in the adjacent node. Other LPDU commands received 
while tin the link rejection condition cause receiving ELLC link stations to 
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retransmit the LPDUR response with the same information field originally 
transferred. 


Upon receipt of an LPDUR response, ELLC link stations prepared to resume normal 
operation of the link transfer an LSABME command LPDU with 'P=1" across the link 
connection and start Link Reply Timer, LT1. Otherwise, ELLC link stations 
initiate the link disconnection procedure described in "Link Disconnection" on 
page IJI-K-15; or, cause a clearing or resetting of the underlying virtual circuit. 


ELLC link stations may start Link Reply Timer, LT1, on transferring the LPDUR 
response. If Link Reply Timer, LT1, then expires prior to the receipt of an LSABME 
or a LDISC command from the communicating link station in the adjacent node, ELLC 
link stations may retransmit the LPDUR response and restart Link Reply Timer, LTl. 
Following transmission of the LPDUR response LN2 times ELLC link stations may 
reset the link as described in "Link Resetting Procedures”™ on page ITI-K-18. The 
value of LN2 is defined in "Maximum Number of LPDU Transmissions - ( LN2 )" on page 
{I-K-22. 


K.6.3.10 LLCO Rejection Conditions 


ELLC link stations may initiate a resetting procedure as described in "Link Resetting 
Procedures" on page II-K-18 upon receipt, during the information transfer phase, of an 
LPDU with the correct PDUCS, and with one of the following conditions: 

1. the LPDU is unknown as a command or as a response; 

2. the LPDU does not conform to one of the valid formats; 

3. the LPDU information field is invalid; or, 


4. the LPDU contains an invalid LNr as defined in "LLC_Protocol_ Data_Unit_Reject ( 
LPDUR ) Response” on page II-K-9. 


Coding of the information field of LPDUR responses transferred is given in 
"LLC _Protocol._Data_Unit_Reject ( LPDUR ) Response" on page II-K-9. 


Unsolicited LDM - ELLC link stations initiate a resetting procedure as described in 
"Link Resetting Procedures” on page II-K-18 upon receipt, during the information 
transfer phase, of an LDM response or an LPDUR response. 


Unsolicited Response - ELLC link stations may initiate a resetting procedure as 


described in "Link Resetting Procedures" on page II-K-18 upon receipt, during the 
information transfer phase an LUA response or an unsolicited LPDU response with 'F=1'. 


K.6.4 Link Connection Procedures 


K.6.4.1 Initial Connection Establishment 


The ELLC protocols employ the X.25 call set-up procedures described in -- Heading id 
%ch8' unknown -- for initial establishment of link connections. 


K.6.4.2 Connection Recovery 


Procedures are described to allow recovery from certain link connection failures, 
indicated by PSDNs, to be attempted at the LLC level when ELLC has been selected. Link 
failures reported by PSDNS in CLEAR_INDICATION, RESET_INDICATION and 
RESTART_INDICATION packets with the network generated Cause Codes listed in Figure 
K-6, Figure K-7 and Figure K-8 are assumed to be temporary in nature and, therefore, 
potentially recoverable. 


1. Clears 
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ELLC link stations attempt to re-establish virtual calls (switched virtual 
circuits) cleared by PSDNs via CLEAR_INDICATION packets that carry recoverable 
Cause Codes, as defined in Figure K-6, up to LN2 times before indicating © 
link/station INOP to the higher layers of SNA. Connection recovery 1s initiated 
by transferring a CALL_REQUEST packet across the access channel, as depicted in 
Figure K-10. (5), indicating: 


° LLC recovery mode; 
° connection recovery request; and, 
e connection identification information, if required. 


Upon receipt of an INCOMING CALL packet on a logical channel associated with a 
link connection perceived to have a connection recovery pending, ELLC link 
stations cause a clearing of the incoming call by transferring a CLEAR REQUEST 
packet with the Cause Code x'00', "DTE Generated’, and the diagnostic code x'5C', 
"Logical Channel Reserved’. 


Resets 


ELLC link stations only need to log network tnitiated resets, of switched or 
permanent virtual circuits indicated by PSDNs via RESET_INDICATION packets that 
carry recoverable Cause Codes as defined in Figure K-7, for future problem 
determination purposes. Specific recovery action 1s not required in- such 
instances since ELLC LPDU sequence numbering, acknowledgment and re-transmission 
procedures provide adequate data integrity mechanisms to cope with temporary 
failures in this category. 


Restarts 


ELLC iitnk stations treat network initiated restarts, of the X.25 DTE/DCE interface 
indicated by PSDNs via RESTART_INDICATION packets that carry potentially 
recoverable Cause Codes as defined in Figure K-8, as a clearing of all virtual 
calls and a resetting of all permanent virtual circuits at the X.25 DTE/DCE 
interface. 


K.6.5 List of LLC Parameters 


The LLC parameters are as follows: 


K.6.5.1 LLCO_Time-Out_Function - ( LFt ) 


Th2 duration of the LLC time-out function (LFt) is: 


LFt = CLTLeLN2+LTd)deLNd 


where: 


LT1 is a function of the time allowed by link stations between the 
transmission of commands and receipt of the corresponding 
acknowledgment. 


Upon expiration of timer-LT1, Link stations retransmit the 
unacknowledged command with 'P=1" and restart timer LTl. 


LN2 2'1" is the maximum number of transmissions and retransmissions 
of a LPDU following the expiration of time LT1l. 


LTd is typically many time greater than time LT1 and is the time to 
be delayed between consecutive repetitions of LT1eLN2. 


LNd 2'1' is the maximum number of repetitions of LTLleLN2+LTd to be 
performed before declaring the logical link connection to 
be inoperative. 2 


2 Although LTd may be defined as zero, experience suggests that when LTd='"0' and LNd="1" 
2 are used, link connections may often be declared inoperative prematurely, resulting in 
2 unnecessary session outages due to momentary network service disruptions. 
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re, essential that LT1L, LN2, LTd and LNd have default values that can be 
overridden by customers as experience indicates. 


ions start Link Reply Timer, LT1, upon completion of transmission IPDUs 
or SPDU and UPDU commands with 'P=1'. 


The component parts of Times LT1 and LTn for link stations are illustrated in Figure 
K-93 to assist in the succeeding description of Time-limit LT2. 
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Figure K-9. 


Process Maximum time Transmission Propagation Process 
time to seize line |time time time 


represents the end of transmission of the last bit of the LPDU 
requiring acknowledgment by the link station; 

represents receipt of the last bit of the LPDU requiring 
acknowledgment by the communicating link station in the 


adjacent node; 


represents recognition of the LPDU requiring acknowledgment by 
the communicating link station in the adjacent node; 


represents transmission of the first bit of the acknowledging 
LPDU by the communicating link station in the adjacent node; 


represents transmission of the last bit of the acknowledging 
LPDU by the communicating link station in the adjacent node; 


represents receipt of the last bit of the acknowledging LPDU by 
the link station; 


represents recognition of the acknowledgment for the outstanding 
LPDU at the link station; and; 


are the propagation times to and from the link station in the 
aaqjyacent node station, respectively. 


are the stated processing times for the link station in the 
adjacent node and this link station, respectively. 


time to complete transmission of those LPDUs in the acknowledging 
link station's "transmit queue™ that are neither displaceable 

nor modifiable in an orderly manner. 

time to transmit the acknowledging LPDU. 


T? + T2 + T3 + T% + T5 + T& Cminimum value). 


LINK REPLY TIMER - LT1: Components 


K.6.5.2 LRNR Time-out - ( LTn ) 


LTn 
LT1. 
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K.6.5.3 LLCO Time-Limit - ( LT2 ) 


Time-limit LT2 is the maximum time allowed between receipt of a command LPDU from the 
link station in the adjacent node and transmission of an appropriate response LPDU. 
This value is product and configuration specific. LT2 must never exceed the time 
needed to transmit one maximum length frame plus fifty (50) milliseconds. 


The duration of Time-limit LT2 is an LLC parameter that is determined by bilateral 
agreement between communicating link stations. The period of Timer-limits LT2' and 
LT2" for a link station and its counterpart in the adjacent node, respectively, take 
into account: : 


1. the transmission time of the acknowledging LPDU; 
2. the propagation time across the link connection; 


3. br processing times for the link station and its counterpart in the adjacent 
node; and, 


4. the time required to complete transmission of the LPDUs in the transmit queues, at 
both the link station and its counterpart in the adjacent node, that are neither 
displaceable nor modifiable in an orderly manner. 


For example, to insure receipt of an acknowledging LPDU before a link stations 
Link Reply Timer, LT1l, expires, the communicating link station in the adjacent 
node must begin transmission of the acknowledging LPDU early enough to take the 
values of T*, T5 and T*, indicated above, into account. That is to say, the link 
station in the adjacent node must initiate transmission of the acknowledgment 
within at least time T° after ascartaining that an acknowledgment is required. 


For the direction of data transmission from a link station to its counterpart in the 
adjacent node, LT2' indicates the maximum amount of time allowed between receipt, at 
the link station in the adjacent node, of an LPDU requiring an acknowledgment and 
initiation of transmission, by the link station in the adjacent node, of the 
acknowledging LPDU to insure its receipt prior to the expiration of the link stations 
Link Reply Timer, LT1. The value of LT2' must be less than the value of LTl. 


For the direction of data transmission from a link station to its counterpart in the 
adjacent node, LT2' indicates the maximum amount of time allowed between receipt, at 
the link station in the adjacent node, of an LPDU requiring an acknowledgment and 
initiation of transmission, by the link station in the adjacent node, of the 
acknowledging LPDU to insure its receipt prior to the expiration of the link stations 
Link Reply Timer, LT1. The value of LT2' must be less than the value of LTl. 


Given a value for Link Reply Timer LT1, the value of Timer LT2' must be no greater than 
LT1 less: 


- the propagation time across the link connection from the link station 
to its counterpart in the adjacent node; 

- the LPDU processing time at the link station in the adjacent node; 

- the time required to transmit the acknowledgment from the link 
station in the adjacent node; 

~ the propagation time across the link connection from the link station 
in the adjacent node; and, 

- the LPDU processing time at the link station. 


For the direction of data transmission from the remote to the local link station, LT2" 
indicates the maximum amount of time allowed between receipt of an LPDU requiring an 
acknowledgment and initiation of the transmission of the acknowledging LPDU to insure 
its receipt at the remote Link station prior to the expiration of Timer LT1. The value 
of LT2™" must be less than the value of LT1l. 


Given a value for Timer LT1, the value of Timer LT2" must be no greater than LT1 less: 


- the propagation time across the link connection from the link station 
in the adjacent node; 

- the LPDU processing time at the link station; 

- the time required to transmit the acknowledging LPDU to the link 
station tn the adjacent node; 

~- the propagation time across the link connection to the link station. 
in the adjacent node; and, 

- the LPDU processing time at the link station in the adjacent node. 
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K.6.5.4 Maximum Number of LPDU Transmissions - ( LN2 ) 


The maximum number of transmissions and retransmissions of a given LPDU following the 
expiration of Link Reply Timer LT1 is a LLC parameter (LN2) whose value is determined 
by bilateral agreement between adjacent link stations. 


Note: To facilitate throughput enhancement in environments where the quality of 
service exhibited by underlying network services afford adequate data integrity 
support of the retransmission recovery function may be bypassed when the value of LN2 
is equal to one (1). 


K.6.5.5 Maximum Number of Bytes in an IPDU - ( LNi ) 


The maximum permissible number of octets (bytes) in an IPDU is an LLC parameter (LN1) 
which depends upon the maximum length of the information fields transferred across the 
link connection. 


K.6.5.6 Maximum Number of Outstanding IPDUsS - ( Lk ) 


The maximum permissible number (Lk) of sequentially numbered IPDUs that link stations 
may have outstanding (i.e., unacknowledged) at any given time is an LLC parameter 
which can never exceed one hundred twenty-seven (127). The value of '‘Lk' is 
determined by bilateral agreement between adjacent link stations. It is recommended 
that 'Lk' be a parameter whose default value can be overridden. 


K.6.5.7 Link Idle Timer - ( LTi ) 


The period of time that a link station may allow the link connection to remain in the 
idle state (see "Link Channel States" on page II-K-4) before, initiating a procedure 
to protect against half-open link connections by, transmitting an LRR command LPDU. 
oe many times greater than LT1, and typically has a value in the order of (LN2 * 
LT1)72. 


K.7 -LPDU FLOW EXAMPLES 


Sample ELLC LPDU flows depicting initial link establishment, initialization, 
information exchange, recoverable call clearing and connection recovery are shown in 
Figure K-10. 
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Figure K-10. 


Sj DCE DCE LSk 
o CRQ(CiC,e,nul_cid) Oo 0 re) 
e >+ >e INCCIC,e,nul_cid) o 
re) re) >@e 
oO oO oO CAC 
0 CCN e< +< ae 
ooo re) oO 
re) o o oO 
o TDTCSMc) 0 re) ° 
e >@ 
re) oO ro) TDTCUAr) o 
e< e 
o TDTC(CRRc) oO re) oO 
e (Optional) >@ 
fe) oO oO TDTCRRr) o 
e< COptional) e 
0 0 o o 
o TDTCIc,data) ve) oO o 
e >@e 
o o o TDTCIc,data) o 
e< e 
oO 0 re) fe) 
o oO oO oO 
o CLIC€cc,d) re) re) CLI€cc,d) o 
rrr a LEICESTER ih @ >e 
CRQCCr,e,nul_cid) e) o ° 
: >+ >e INC(Cr,e,nul_cid) fe) 
re) oO >e 
oO o ro) CAC 
re) CCN ex< +< 
———————— o oO 
o TDTCRRc) o oO oO 
e COptional) >@ 
re) re) oO TDTCRRr) o 
e< (Optional) e 
oO ve) o oO 
o TDTCIc,data) re) re) oO 
e >@¢ 
o re) oO TDTCIc,data) o 
e< ° 
re) e) oO oO 
o oO o re) 
o CLR(cc,d) re) oO | re) 
° >t e ClIi(€cc,d) o 
oO NCC Cnn > 
o< re) Tce 
fe) re) o< 
re) o o re) 
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cc: Clearing Cause code 
cid: Connection Identifier 

Cr: Connection Recovery Indication 

d: Diagnostic code 

e: ELLC protocol identifier 

Eo Information command 

iC: Initial Connection indication 

LSCi): Link Station 'i'! 
nul: Null 
SM: SABME Unnumbered command 
UA: Unnumbered Acknowledgement response 


FLLC: 
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The following notes are keyed to Figure K-10. 


dg 


APPENDIX K: 


Initial Connection Initiation 


Link connection establishment 
packet, to the network access DCE, with the following parameters in the CUD field: 


is 


°. (10) - Initial connection indicator 
e Ce) - Extended LLC protocol indicator 
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initiated by the transfer of a CALL_REQUEST 
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e (cid) - Connection identifier Coptional ) 
2. Link Initialization 


Link initialization is initiated by the transfer of a DTE_DATA packet containing 
an LSABME command LPDU in the user data field and may be terminated either by the 
receipt of an LUA command LPDU or receipt of an LUA command LPDU followed by an 
exchange of DTE_DATA packets containing LRR command and response LPDUs, 
respectively. 


3. Information Exchange 
Information is exchanged between adjacent link stations by the transfer of DATA 
packets or packet sequences with the user data field containing an information 
command LPDU. 

4. Network Initiated Call Clearing 


Network initiated call clearing is signalled by the transfer of unsolicited 
CLEAR_INDICATION packets to both the calling and called link stations containing: 


e (cc) - Cause Codes in the Clearing Cause field. 
e (d) - Diagnostic Code in the Diagnostic Code field. 


5. Connection Recovery 
Link connection recovery, following a recoverable network initiated call clearing 


is initiated by the transfer of a CALL _REQUEST packet, to the network access node, 
with the following parameters in the CUD field: 


e (Cr) - Connection Recovery indication 
e Ce) - Enhanced LLC protocol indicator 
e (cid) - Connection identifier Coptional) 


6. Link Initialization/Assurance 


Link re-initialization is accomplished by an exchange of LRR command and response 
LPDUs, respectively. 


7. Continue Information Exchange 
Proceeds as in item 3. above. 
8. Connection Termination 


Termination of a link connection is initiated by the transfer of a CLEAR_REQUEST 
packet, to the network access node, containing the following parameters: 


e (cc) - Clearing Cause Code; and, 


e (d) - Diagnostic Code. 
K.8 LINK STATION STATES AND ACTIONS 


K.8.1 Chart Description 


Operation of the ELLC protocol for link stations is formalized by the charts contained 
in "Link Station States and Actions” on page II-K-32 for the link connection states 
defined in "ELLC STATE DESCRIPTIONS” on page IJI-K-26. Action(€s) taken by link 
station(s) as a result of particular stimuli are shown at the intersection of the 
various link connection states and the stimulus. ELLC link connection states include 
the predicate conditions defined in "PREDICATES™ on page II-K-27 and the state 
variables defined in "State Variables" on page II-K-28, either or both of which are 
indicated under the heading(s) 'P: V:' Cwhen appropraite) in the charts in "Link 
Station States and Actions" on page IJI-K-32. ELLC stimuli include the events as well 
as the command and response LPDUs defined in "ELLC Stimuli™ on page II-K-28. 


Information contained at these intersections specify the action(s) taken (denoted by 
two uppercase letters 'LL'), the basic procedure executed (denoted by the small 
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letters "bp" concatenated with an uppercase letter 'L'), the PDUCsS) transferred (Cif 
any), signified by the protocol data unit identifier enclosed in brackets with any 
required parameters [PDU_id(pl,..,pn)] and the new state of the link connection to be 
entered Cif any). 


The PDU transferred, [PDU], may be any of the LLC command or response LPDUs listed in 
"Commands Sent and Received" on page IJI-K-29 and "Responses Sent and Received" on page 
II-K-29 and a small letter 'c' or 'r' may be appended signifying command or response, 
respectively; or the LPDU indicated by the PDU output scheduling algorithm signified 
by an undefined protocol machine [PDU_Out_UPM]. XPo, TPo and LPo signify the output 
PDU indicated by execution of the basic procedures X, T and L, respectively. 
Additional appendages that specify the value of the P-bit for command LPDUs and the 
F-bit for response LPDUsS when necessary, include: 


0 - signifying a P/F-bit value of '0'; 

1 - signifying a P/F-bit value of "1'; 

" - signifying a P/F-bit value equal to the value of the variable, Vf; and 

'" = signifying an F-bit value equal to the value of the P-bit tn the received 
command LPDU to which it responds. 


In the event the PDU transferred causes a packet level clearing or resetting of the 
associated virtual circuit, an appropriate diagnostic code is included (see Appendix F 
for DTE Generated Diagnostic codes used when the virtual circuit for SNA-to-SNA 
connections are cleared, reset or restarted). When no [PDU] is indicated, nothing 15s 
transferred across the link connection to the link station in the adjacent node as the 
cesult of that particular stimulus. 


Applicable ELLC link connection state transitions are specified under the heading New 
State when the link connection is to be placed in a different state following’ the 
specified action(s) and/or PDU transfer. Link connections remain in the current state 
when no new state to be entered is specified at a particular intersection. 


Alternative procedures, denoted by lower case letters 'l'" or the word ‘or’ under the 
"ALT' heading, are specified where appropriate. 


References to clarifying notes (denoted by '#n' Cwhere ‘n' is a decimal digit) under 
the "ALT" heading) are also provided at certain intersections, where deemed necessary, 
to explain extenuating circumstances considered essential to proper operation of the 
protocol, including: 


1. When an exchange of link station identification information is not required prior 
to link set-up. | 


2. The virtual call (Cswitched virtual circuit) supporting the link connection is 
cleared (e.g., CLEAR _REQUEST or CLEAR_INDICATION) the underlying virtual circuit 
is terminated and the link connection placed in the INOPERATIVE state. 


The sample sequences shown in Figure K-10 on page JI-K-24 represent one example of how 
the tables may be used. 


K.8.1.1 ELLC STATE DESCRIPTIONS 


INOPERATIVE:. The link station, not having resources allocated sufficient to support 
link connection, is non-functional and reacts positively only to link activation 
stimulus as specified in "INOPERATIVE State” on page II-K-32 


LINK CLOSED: The link station, having sufficient resources to support link connection 
allocated, reacts to stimuli as specified in "LINK_CLOSED State" on page II-K-33 when 
authorized and prepared to support link initialization. 


LINK OPENING: Link stations having initiated the link set-up procedure, by 
transferring an SABME command LPDU across the link connection, react to stimull as 
specified in "LINK_OPENING State” on page II-K-35 pending receipt of link set-up 
confirmation CUA response LPDU) from the link station in the adjacent node. 


LINK_CLOSING: Link stations having initiated the link disconnection procedure, by 


transferring a DISC command LPDU across the link connection, react to stimuli as 
specified in-- Heading id 'closg'’ unknown = 
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LINK_OPENED: Link stations having completed the link set-up procedure react to 
stimuli as specified in "LINK_OPENED State” on page II-K-39 in the absence of error or 
exception condition(s) effecting the associated link connection. 


CHECKPOINTING: Link stations having transferred an S-format command LPDU with 'P=1' 
across the link as a result of the expiration of the link reply timeout, Timer LTl, on 
the associated link connection react to stimuli as specified in "CHECKPOINTING State" 
on page II-K-42. 


LINK _RESETING: Link stations having received an SABME command LPDU from the link 
station in the adjacent node, initiating the link resetting procedure, react to 
stimuli as specified in "LINK_RESETING State” on page II-K-48 until the resetting 
procedure is completed by the transfer of either a UA or DM response LPDU as directed 
by a higher level function. 


LINK _ RECOVERY: Link stations having received a FRMR response LPDU from, or 
transferred a FRMR response to, the link station in the adjacent node react to stimuli 


as specified in "LINK _RECOVERY State” on page II-K-49 until a resetting procedure is > 
completed for the link. 


K.8.1.2 PREDICATES 


ELLC rredicate conditions include: 


P: which signifies general condition(s) for the link connection and may take on the 
values: 


1. "Nul’® — signifying that no outstanding exceptional general conditions exists for 
the link connection. 


2% YRIN' — signifying that an out-of-sequence IPDU has resulted in the transfer of an 
REJ command or response LPDU to the link station in the adjacent node. 


Pb Busy: Signifies condition(s) for the link relative to resource constraints that 
temporarily prevent acceptance of I-format LPDUCs): 


e "B' by both the local link station and its communicating partner in the adjacent 
node; 

° 'L' by the local link station; 

e 'N’ by neither the local nor its communicating partner in the adjacent node; or, 


° "R"' by the Link station itn the adjacent node. 


Pc_Pending Command Identifies the pending command LPDU when a command transmission is 
awaiting completion of a checkpointing cycle, and may take on the values: 


° "D' signifying a Disconnect command; 

° *R’ signifying a Receitve_Ready command; 

e 'T" signifying a Test command; 

@ "X' signifying an Exchange_Identification; or 


® 'N' signifying that no command LPDU is pending. 


Pr Recovery.Status: 


e "Nul’ signifying no recovery procedure in process; 

e "L" signifying recovery due to a locally detected PDU_ Rejection condition in 
process; or, 

° "R' signifying recovery due to a remotely detected PDU_Rejection condition in 
process. | 


Pt_TEST.Status: 
e "Nul’ signifying that no TEST of the link connection is 1n process; 


° "I" signifying that an tncoming TEST response LPDU from the link station in the 
adjacent node is pending; 
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° "OG" signifying that an outgoing TEST response LPDU to the link station in the 
adjacent node is pending; 


e "IO"® signifying that an incoming TEST response LPDU from and an outgoing TEST 
response LPDU to the link station in the adjacent node are both pending. 


Px_XID.Status: 


e "Nul™" signifying that no exchange of identification information (XID) 1s in 
process; 


° 'I' signifying that an incoming XID response LPDU from the link station in the 
adjacent node 15s pending; 


e 9? signifying that an outgoing XID response LPDU to the link station in the 
adjacent node is pending; 


e "IO" signifying that an incoming XID response LPDU from and an outgoing XID 
response LPDU to the link station in the adjacent node are both pending. 


K.8.1.3 State Variables 


ELLC state variables include: 


Va ~ Acknowledged LPDU: containing the last Nr value received, or '0* immediately 
following completion of the link set-up procedure; 


Vf ~ Final Bit Value: containing the value for a final bit pending transmission (e.g., 
associated P-bit value received). 


Vi ~ Initialization Status: Signifies link initialization progress and may take on 
the values: 


e "L*® signifying locally initiated link set-up; 

¢  'R" signifying remotely initiated link set-up; 

e "B’ signifying locally and remotely initiated link set-up; 

° 'P* signifying initialization confirmation pending; or, 

o Nul® signifying initialization completed/not started. 

Vr — Next IPDU In: denoting the sequence number (Ns) of the next in-sequence I-format 
orale be received across the link connection from the link station in the adjacent 
Vs — Next IPDU Out: denoting the sequence number (Ns) of the next in-sequence I-format 


~PDU to be transferred across the link connection to the link station in the adjacent 
node. 


K.8.1.4 ELLC Stimuli 


ELLC protocol stimuli include the events, commands and responses described itn the 
following paragraphs. 


Events 


e L3RDY — PACKET_LAYER CLevel 3) READY: representing a signal from the X.25 Packet 
Layer (level 3) that the underlying virtual circuit, in the READY (p4 or dl) 
state, 1s prepared to support a link connection. 


e LSTRT - LINK_START: representing a higher level stimulus to establish a link 
connection to a communicating link station in the adjacent node. 


® LSTOP - LINK_STOP: repesenting a higher level stimulus to terminate the link 
connection to the communicating link station in the adjacent node. 
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L3NOP — LEVEL_3_INOPERATIVE: representing a signal from the X.25 Packet Layer 
Clevel 3) that the underlying virtual circuit, in the INOPERATIVE state, is no 
longer capable of supporting a link connection. 


ELBSY - ENTER_LOCAL_BUSY: representing a signal from the DLC.X25 Manager 
informing the link station of a local resource constraint that temporarily 
prohibits the continued acceptance of I-format LPDUs. 


XLBSY — EXIT_LOCAL_BUSY: representing a signal from the DLC.X25_ Manager informing 
the link station of the removal of an existing local resource constraint. 


ELPDU — ERRONEOUS _ LLC_PROTOCOL_DATA_UNIT: representing receipt of an erroneous 
LPDU Ce.e., one containing an unidentifiable LLC command or response, etc.) on the 
link connection. 


XCHID a EXHCANGE_IDENTIFICATION: representing a higher level 
request/authorization to transfer LLC link station identification information. 


LTEST — LINK_TEST: representing a higher level request/authorization to transfer 
LLC link test data. 


SDATA ~- SEND_DATA: representing a higher level request for the transfer of user 
data to the link station in the adjacent node. 


ELTIX — ELLC_LINK_REPLY_TIMEOUT_EXPIRATION: representing expiration of the LLC 
link reply timeout, Timer LTl. 


ELTiX — ELLC_LINK_IDLE_TIMEOUT_EXPIRATION: representing expiration of LLC link 
query timeout, Timer LTi. 


Commands Sent and Received 


LI —- I-format LPDU: representing a DATA packet or packet sequence containing an 
I-format LPDU in the user data field(s). 


LSM — LLC_SET_MODE CLSABME): representing a DATA packet containing a Set_Mode 
command LPDU (LSM) in the user data field. 


LDC — LLC_DISCONNECT (LDISC): representing a DATA packet containing a Disconnect 
command LPDU (LDC) in the user data field. 


LXC — LLC_EXCHANGE_IDENTIFICATION: representing a DATA packet or packet sequence 
containing an Exchange_Identification command LPDU C(LXC) in the user data 
field(s). 


tTC -— LLC_LOGICAL_LINK_TEST: representing a DATA packet or packet sequence 
containing a Link_Test command LPDU (LTC) in the user data field(s). 


LRR — LLC_RECEIVE_READY: representing a DATA packet containing a Receive_Ready 
command LPDU CLRR) in the user data field. 


Responses Sent and Received 


LDM -—- LLCO_DISCONNECTED_MODE: representing a DATA packet containing a 
Disconnected_Mode response LPDU (LDM) in the user data field. 


LPR — LLC _PDU_REJECT: representing a DATA packet containing a PDU_Reject response 
LPDU CLPR) in the user data field. 


LUA -— LLC_UNNUMBERED_ACKNOWLEDGE: representing a DATA packet containing an 
Unnumbered_Acknowledge response LPDU CLUA) in the user data field. 


LXR ~- LLC_EXCHANGE_IDENTIFICATION: representing a DATA packet or packet sequence 
containing an Exchange_Identification response LPDU (LXID), including link 
station identification information, in the user data field(s). 


LTR - LLC_TEST: representing a DATA packet or packet sequence containing a 
Link_Test response LPDU (LTR), including test data, in the user data field(s). 


LRR -— RECEIVE_READY: representing a DATA packet containing a Receive_Ready 
response LPDU (LRR) in the user data field. 


APPENDIX K: Enhanced Logical Link Control — ELLC | II-K-29 


SNA/X.25 DTE/DCE Interface 
K.8.1.5 BASIC PROCEDURES 


Basic procedures defined for ELLC link stations, speuisied at the ontareeckion of a 
state/condition/option and a stimulus, denoted by a small letter 'bp' concatenated 
with a capital letter 'L' (bpLl), include: | . 


bpA ~ Acknonledgment: Process the received Nr value according to the procedure 
specified by CHART_A in "Acknowledgment" on page II-K-50 and if Va<Nr<Vs : Va=Nr, RT1; 
Va<Nr=Vs : Va=Nr, TT1, ITi; ELSE ; NS. : | 


bpL ~ Limit: Perform the procedure specified by CHART_L in "Limit™ on page II-K-51 
which increments the (re)-transmission count 'Ct® by one, then if Ct=N2 : report the 
failing procedure to, and await further direction from, a higher level of SNA; Else : 
retry the indicated protocol procedure. 


bPpR —~ Rejection: Process the received REJECT command/response LPDU according to the 
procedure specified by CHART_R in "Rejection™ on page ITI-K-51 and if Va<Nr<Vs 
Va=Vs=Nr, RT1; Va<Nr=Vs : Va=Vs=Nr, TT1, ITi; ELSE : Vs=Nr. 


bpT ~ TEST: Perform the procedure specified by CHART_T in "Link Test™ on page II-K-51 
with the result that if Pt=Nul : Pt=Ip, TTi, RT1, Ct="'0", CLTC!] > CHECKPOINTING; 
Pt=Rp : IH, Pt=Nul, CLTRCF=Vf,id)]; Pt=IRp : IH, Pt=Ip, [LTRCF= Vf,id)]; Else : LE. 


bPpX —™ EXCHANGE_IDENTIFICATION: Perform the procedure specified by CHART_X in 
"Exchange Identification” on page II-K-51 with the result that if Px=Nul : Px=Ip, TTi, 
RT1, Ct="'0', [LXC!] > CHECKPOINTING; Px=Rp : IH, Px=Nul, (LXRCF=VfF,id)]; Px=IRp : IH, 
Px=Ip, CLXRCF =Vf,id)]; Else : LE. 


K.8.1.6 Actions 


Actions taken by ELLC link stations, denoted at the intersection of a 
state/condition/option and a stimulus, are identified by two capital letters ‘LL’ 
which are defined as follows: 


DB - Discard BTU: Discard the contents of the information field of the received PDU 
and take no further action as a result of its receipt. 


DL - Disable Link: Destroy the link connection, releasing the Access Channel and 
Media Access Port associated with the Link appearance. 


EL - Enable Link: Establish a link connection by associating a specific Access 
Channel and Media Access Port as required to create a link appearance. 


FB - Forward BTU: Forward the received Basic Transmission Unit to the higher level 
using protocol entity. 


IH - Inform Hisher Layers: Informa higher layer of SNA of the occurrence via internal 
signalling mechanisms. 


IP - Ignore Protocol Data Unit: Take no action and ignore the received protocol data 
unit in its entirety. 


ITi - Initiate Query Timer, LTi: Initiate a logical link timeout for the duration of 
Query Timer, LT1 


LE - Local Procedure Error: Representing an internal signalling error or illogical 
protocol sequence on the part of the ELLC link station that may be either’ ignored or 
reported to a higher layer of SNA for analysis. 


NA - Not Applicable: Identifies events/actions/responses that cannot occur for a 
given state/condition/alternative. 


NS ~- No Specific Action: No specific action is required by the ELLC link station 
protocol. 


QL - Queue LPDU: Place the output BTU in the information field of an Information LPDU, 
place the LPDU on the outbound queue for the associated logical link, and pass control 
to the PDU_Out_UPM. 
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RE - Remote Procedure Error: Representing a protocol procedure error on the part of 
the ELLC link station in the adjacent node that may be either ignored or reported to a 
higher layer of SNA for future analysis. 


RS - Report Status: Report the current status of the ELLC link station to a higher 
level of SNA. 


SL - Set-Up Link: Initiate the link set-up procedure described in §-4.5.4.1. 


TC - Terminate Contact: Terminate the SNA_CONTACT phase and signal CONTACTED to a 
higher level of SNA. 


TL - Terminate Link: Terminate the link initialization procedure and transfer an 
unsolicited DISCONNECTED_MODE response to inform the link station in the adjacent 
node. 


TT¥i - Terminate Timer LTi: Terminate LLC Query Timer, LTi. 
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K.8.2 Link Station States and Actions 


K.8.2.1 INOPERATIVE State 


CHART 1-E: EVENTS in INOPERATIVE State 
Stimuli P: V: ALT] ActionCs) 


c 

: 
: 
: 
: 
: 
i 
r 
: 


CHART 1-S: S-format LPDUs in INOPERATIVE State 


CHART 1-U: U-format LPDUs in INOPERATIVE State © 
Stimuli P: VW: ALT 

LSM|[LUA 

LDC|LDM 
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K.8.2.2 LINK_CLOSED State 


CHART 2-E: EVENTS in LINK_CLOSED State 


Stimuli P: V: ALT] Action(s) C[PDU Transfers] New State 


LSTRT cttt+xNult+ 
tNul SL, Vi=L, Ct=0, TTi, RT1 LINK_OPENING 


iR SL, Vi=P, TT1, ITI LINK_OPENING 


LSTOP TL, Vi=Nul, TT1l, ITi [LDM®? ] 


Ct<<LN2+ 
xI {10 


tI]|I0 
ELSE 


CHART 2-I: I-Format LPDUs in LINK_CLOSED State 


Stimuli P: V: ALT! Action(s) [PDU Transfers] New State 
cn ee ee ae end 


IP 
a es: 


CHART 2-S: S-format LPDUs in LINK_CLOSED State 


| Stimuli P: V: Action(s) - [PDU Transfers] 
: 
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CHART 2-U: U-format LPDUs in Received LINK_ CLOSED State 


Stimuli P: V: ALT] Action(s) CPDU peStetGee New State 


LDC 
LUA 
LDM 
LPR 


CHART 2- 
Stimuli 


LTC 


LTR O* 


Nul+iNul[R IH, Vi=FR, Vf=P, ITi 


1P IH, Pc=Pt=Px=Va=Vf=Vs=0, ITi CLUA"]} LINK_OPENING 


clSE LE 


i ae 


U: U-format LPDUs in LINK_CLOSED State (Continued) 


P: V: ALT Action(s) [PDU Transfers] New State 


IH, Px=0, Vf=P 
xI TH, Px= Nul, TTl 


xI0 IH, Px=0, Raps 
ELSE IP_CRE) 


taf a 


tI IH, Pt=Nul, TT1 


tio IH, Pt=0, TT1 


ELSE IP_CRE) 
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K.8.2.3 LINK_OPENING State 


CHART 3-E: EVENTS in LINK_OPENING State 


a 
a 
r 


CHART 3-E: EVENTS in LINK_OPENING State (Continued) 


Stimuli Ps: V: Action(s) [PDU Transfers) New State 


CHART 3-I: I-Format LPDUs in LINK_OPENING State 


Stimuli P: V: ALT] Action(s) [PDU Transfers] New State 


CLRRr®°] LINK_OPENED 


[LRRr?] LINK_OPENED 
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CHART 3-S: S—format LPDUs in LINK_OPENING State ; 


Stimuli P: WV: ALT] Action(s) | [PDU Transfers] New State 
eluwminee pe 


LRRCO) | 
LRJCO)c? GR 


IH, Pb=Nul, Vi=Nul, RTi CLRRr?] 


LINK_OPENED 


LNRCO)c? LINK OPENED 


CLRRr? J 


ELSE 


CHART 3-U: U-format LPDUs tn LINK_OPENING State > 


Stimuli P: Vz: ALTI Action(s) [PDU Transfers] New State 
ViER» TTl, ITi CLUA']] 
IH, Vi=Nul, TTl, ITi C[LDM'] LINK CLOSED 


IH, Pc=Pt=Px=Va=Vf=Vi=FVr=Vs=Nul, TTi, 
RTi CLRRce?]| CHECKPOINTING 


LINK_CLOSED 


IP_CRE) 
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K.8.2.4 LINK_CLOSING State 


Stimuli P: V: ALT| Action(s) | ————sCPDU Transfers] | New State 
pL 
E 


rr 
m 


| ome 
m 


| ood 
m 


Se le 
mipmym 


aad 
m 


I 


CHART 4-I: I-Format LPDUs in LINK_CLOSING State 


ELTiX 


Stimuli P: V: CPDU Transfers] 
L 


New State 


CHART 4-S: S-format LPDUs in LINK CLOSING State 
New State 
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CHART 4-U: U-format LPDUs in LINK_CLOSING State. 


Stimuli P: V: ALT! ActionCs) C[PDU Transfers] New State 


IP_CRE) 


IP 
IP 


CRED 
(RE) 
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K.8.2.5 LINK_OPENED State 


CHART 5-E: EVENTS in LINK_OPENED State : 


Action(s) [PDU Transfers] 
a 
A 
bL{B LE 

RJN+[bR 
ELSE 
bL 


Pb=Nul, RT1, Ct=0 CLRRc!] 


Pb-R, RT1, Ct=0 C[LRRc?] 


Pb=Nul, TTi, IT1, Ct=0 


Pb=R, TTi, RT1, Ct=0 [LRRc?] 


CHECKPOINTING 
CHECKPOINTING 


bB 
RJN+t+bL 
RJN+bB 
ELSE 


CHECKPOINTING 
CHECKPOINTING 


Px=I, TTi+ RTl, Ct=0 


IH, Px=Nul 


—_—__ lO TPlUlC lOO ea TUTE EEE eee eee 


IH, Px=I 


CHECKPOINTING 


Pt=I, TTi1, RT1, Ct=0 


—_—eas oe eel ell ell Pee eee eee eee eee ee ee 


CHECKPOINTING 


IH, Pt=It—“‘iéSOSOSCSC;*;*;*;*;!COEST 
CE 
ae a aE 
IH_(RE), TT1, ITi, Pr=l [LPR°J| LINK RECOVERY | 


RJN+]bR RT1, Ct=0 CLRRc?]} CHECKPOINTING 
RJN+bL [|B RT1, Ct=0 CHECKPOINTING 


bL|B IT1, Ct=0 . CHECKPOINTING 


ELOE IT1, Ct=0 CLRRc?J]| CHECKPOINTING 


APPENDIX K: Enhanced Logical Link Control — ELLC II-K-39 


MMMM PNPNMNMMMMNMNMMNMNNMNNMNLINMNMNMNMNMNNNMNNNNNNNMNNNNMNNNNMNNNNNMAMNNMNNNNMNNMNMNNNNN NN NNNAN 


SNA/X.25 DTE/DCE Interface 


CHART 5—I: I-Format LDPUs in LINK_OPENED State 
LIic]r® RJN bpA, FB, P=Nul [PDU_Out_UPM] 
bLIB.=Ssi(‘<ié‘Y‘é pA) DBO (sstst*~<“<i<‘i‘i;é;™~C: CERN 
—bR 
RJN+bL|B 
RJN+bR 
ELSE 
LIic? RIN 
bL|B 
RJN+bL |B 
RJN+bR 
ELSE 


LIir? ELSE Va=Vs=Nr, TT1, ITi, Pr=L CLPR°]| LINK_RECOVERY 


Llec|r° RJN,bLIB 
RJN+bL |B 
bR 
RJN+bR 
ELSE | 


LIec? RJN,bL|B 
RJN+bL]B 
bR 
RJN+bR 
ELSE DB, P=RJN 


LIer? ELSE IH_CRE), Va=Vs=Nr, TTL, ITi, Pr=L [LPR°J| LINK_RECOVERY 


= 7 


bL 
RJN+|bB 
LINK RECOVERY 


ELSE 
RJN]bL 
RJN+|bB 
ELSE 
-RJN+bL 
RJN+bR 


LRRc? 


LRRr? IH_CRE), Va=Nr, TT1, ITt, Pr=l CLPR°] 


LINK_RECOVERY 


IH_CRE), Va=Vs=Nr, TT1, ITi, Pr=L [LPR®°] 


ELSE 
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CHART 5-S: S-format LPDUs tn LINK_OPENED State (Continued) 


Stimuli P: V: ALT! Action(Cs) [PDU Transfers] New State 


LNRce|r® RJNtbL 7 
bNul 


bL 
LINK_RECOVERY 


LNRr? bL 


TH_C(RE), Pb=B, Va=Vs=Nr, TTl, aR Ese 


IH_CRE), Pb=R, Va=Vs=Nr, TTl, cen oa 


LINK RECOVERY 
RJN|bL | 
bB 


RJN 
RJN+[bL 
RJN+|bB 
ELSE 
bB 
RJN+bR 


Pb=L, Pr=L 


IH_CRE), Pb=Nul, Va=Vs=Nr, TTL, ITi, 
Pr=L 


LINK_RECOVERY 


LINK_RECOVERY 
LINK_RECOVERY 


ELSE IH_(RE), Va=Vs=Nr, TTl, ITi, Pr=l CLPR®] 


CHART 5-U: U-format LPDUs in LINK_OPENED State 


Stimuli P: V: ALT] Action(s) [PDU Transfers] New State 
IH, Vi=R, VF=P, TT1, ITi | LINK_RESETING 


IH, TT1l, IT} CLUA'] LINK_CLOSED 
TH_CRE), TT1, ITi, Pr=e CLPR°J| LINK_RECOVERY 


IH, TTl, LINK_CLOSED 
IH, TTl, LINK_RECOVERY 
TH_CRE), Px=Nul, TT1, ITi, Pr=R CLPR°]} LINK_RECOVERY 


IH_CRE), Pt=Nul, TT1, ITi, Pr=R CLPR°]] LINK RECOVERY 


ITi, Ct=0, Pr=R 
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K.8.2.6 CHECKPOINTING State 


CHART 6-E: EVENTS in CHECKPOINTING State 


Stimuli P: V: ALT] Action(s) [PDU Transfers] 


L3RDY 
LSTRT 


New State 


cNul 


RJN+t+cR 
ELSE 


RJN+[cR 

RJN+|bR Pb=B, Pc=Nul 
bL|B 

ELSE 


[LRRr°] 


CLXR"™] 
IH, Px=I 


IH, Pt=Nul CLTR"] 
IH, Pt=I | CLTR™] 


CPDU_Out_UPM] 


ITH_CRE), TT1, ITi, Pree 


LINK_RECOVERY 


t+x#0 Ct=Cttl 
Ct=LN2 IH, IT1, IT 


t+xNul 


x0 | IO+ 
Ct<LN2 


tO|I0+ 
Ct<LN2 


LINK_CLOSED 
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CHART 6-I: I-Format LPDUs in CHECKPOINTING State 


Stimul} 


P: V: ALT] Action(s) CPDU Transfers] 
LIic|r® RJN+tcRt 


aNr<Vs P=Pc=Nul, FB 
<NrsVs{| P=Pc=Nul, Va=Nr, FB 


cRt 
aNr<Vs Pce=Nul, FB 


<NrsVs Pe=Nul, Va=Nr, FB 


bLtaNr<Vs DB 


RJN|RJN+bL 


ELSE 


<NrsVs | Va=Nr, DB 
aNr<Vs P=Nul, FB 

<NrsVs Va-=Nr, P=Nul, FB 
aNr<Vs FB 

<NrsVs Va=Nr, FB 


RJN+cR+ 


aNr<Vs P=Pc=Nul, FB 
a<NrsVsj P=Pc=Nul, Va=Nr, FB 


cR+ 
altir<Vs Pce=Nul, FB 


a<NriVs Pc=Nul, Va=Nr, FB 


bLtaNr<Vs DB 


RJN|RJNtbL 


a<NrsvVs Va=Nr, DB 


Va=-Nr, P=Nul, FB 
aNr<Vs FB 
a<Nrsvs Va-=Nr, FB 


ae | oom en (| eat el cm om 
Spee to Lote te = 
A m9 | 7 =z. a 70 70 7 
A 73 7 A r° 70 70 AB 
| a | ao | a | a | 
fo] °o oS °o So ° So ° 
ocmad | tod flecwadl Kecenl [ a a 


—_—_ eS eer EPO ee elle lle eel lel 


—_—__ ee eel eee eee eee lee Oe eee eee 


New State 


[LRRr®?] 


C[LRRr®] 


[LRRr?] 


LIec|r® cRtaNr<Vs 


a<NrsVs = Va=Nr, DB, P=RJN 


RJNtcR+t 


aNr<Vs DB, P=RJN 
a<NrsVs Va=Nr, DB, P=RJN 


bLtaNr<V5s DB, P=RJN 


a<NrsVs Va=Nr, DB, P=RJN 


RJN|[RJN+bL+ 
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aNr<Vs 


DB, P=RJN 
a<NrsVs Va=Nr, DB, P=RJN 
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CHART 6-I: I-Format LPDUs in CHECKPOINTING State CContinued) 
Stimuli P: V: ALT] Action(s) CPDU Transfers] New State 


LIec} cRtaNr<Vs Pc=Nul, DB, P=RJN CLRJri] 
a<NrsVs Pc=Nul, Va=Nr, DB, P=RJN 
RJN+tcR+ 
aNr<Vs Pe=Nul, DB, P=RJN 
a<NrsVs | Pc=Nul, Va=Nr, DB, P=RJN 
bLtaNr<Vs | DB, P=RJN 
} | Ss Va=Nr, DB, P=RJN 
aNr<V5s 
a<NrsVs 
RJNt+bL+t 
aNr<Vs 
aNr<Vs DB, P=RJN 
| ~a<Nr<Vs | Va=Nr, DB, P=RJN os ELRJr?] | 
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CHART 6-S: S-format LPDUs in CHECKPOINTING State 


Stimuli P: V: ALT] Action(s) [PDU Transfers! | New State 


LRRc|[r® cR = 
RJN+|[bL+ 
aNr<Vs 
a<NrsVs = 
RJN+bR+cR+ 
aNr<Vs IH, Pb=Nul 
a<NrsVs IH, Pb=Nul, Va=Nr 
ELSE 
aNr<Vs 
a<NrsvVs = 


RJN+|bL+ 


aNr<Vs CLNRr? J 


a<NrsVs 
RJIN+bR+cRt+ 
aNr<Vs 


a<NrsvVs IH, Pb=Nul, Va=Nr 
ELSE 
aNr<Vs 


a<NrsVs 


 sausamenicohatsaes 
LNRc|r® bNultcR = 
bL+cR = = 
RJN+cR = = 
RJN+bL+t 
aNr<Vs | | 
aNr<Vs 
a<NrsVs 


bNul+cR = = CLRRr?!] 


bL+cR 
_RJN+t+bL+ 
aNr<Vs 


a<NrsVs 
RJN|RJINtcRt 
aNr<Vs 


a<NrsVs 


RJNt+bRtcRt 
aNr<Vs 


aNr<Vs 
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a<NrsVs CLRRr?] 
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CHART 6-S: S-format LPDUs in CHECKPOINTING State (Continued) 


Stimuli P: V: ALT] Action(s) | -LPDU Transfers] New State 


LRJc[r® cRtERJNt+bL = 


bLtaNr<Vs 


a<NrsVs | 
RJNtbRtcR+ ----- om ee ee em Oe me mr em emer eee 
aNr<Vs 


IH, Pb=Nul, Va=Nr 


= — = = Oey anere td Cd ~— Cae —_ a= wan a —_— aan = enw = m_— 


aNr<Vs 


a<NrsVs 


cRtaNR<Vs CLRRr?] 7 
aNRSVs = 
RJN+bL : = 
bLtaNr<Vs5s 
a«Nrsvs 2= | 
RIN¢tcRt f-e—_——— ee eee He eee er ee er KK 
aNr<Vs 
a<NrsVs = 
RINt+tbRtcRt F—-— - e-em eee er em er me mM eM Ke Ke eK eK eK 
aNr<Vs IH, Pb=Nul | 
IH, Pb=Nul, Va=Nr | 
aNr<Vs | 
a<NrsVs CLRRr!] 
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CHART 6—-U: U-format LPDUs in CHECKPOINTING State 


_ Stimuli P: Vs: ALT 


Action(s) 
IH, 


Vi-=R, 


Vf=P, 


TT1, IT1 


TH_CRE), TT1, ITi, Pr=b 
IH, TT1, ITi 

IH, TT1, ITi, Ct=0, Pr=R 
IH, Vf=P, Px=R 


LXR° |? cNul [Rt 


TH_CRE), TT1, ITi, 
IH, Px=Nul, RT1 
IH, Px=0, RT1 


Pe=Nul, TTi, RT1, Ct=0 


Pe=Nul, Px=I, TTi, RT1, Ct=0 
Pe=Nul, Pt=I, TTI, RT1, Ct=0 


LTR°[? cNull]R+t 


APPENDIX K: 


tNul [0 TH_CRE), TT1, ITi, 
tI TH, Pt=Nul, RT1 


tI0 TH, Pt=0, RT1 


CLPR®°] LINK RECOVERY 
CLRRc? J] 
C[LRReo? Jj 


LINK_CLOSING 


AEE 


(LTC! Cdata)] 


CLPR°]} LINK_RECOVERY 
[LRRc!] 
[LRRc?] 


Pe=Nul, TTi, RT1, Ct=0 


LINK_CLOSING 


Pe=Nul, Px=I, TTi, RT1, Ct=0 


—_—__ sb eam ae SPO ee eel OU eel Pel eel eee eee eel eel eee ee 


Pc=Nul, Pt=I, TTI, RT1, Ct=0 
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K.8.2.7 LINK_RESETING State 


CHART 7-E: EVENTS in LINK_RESETING State 


Vi=P, Va=Vr=Vs=0, ITi [LUA™] 


ELBSY bNUL 


ELPDU | IH_CRE), TT1, ITt, Pr=et [LPR°] 
ELT1X IH, IT 


CHART 7-I: I-Format LPDUs tn LINK_RESETING State 


Stimuli P: V: ALT? Action(s) [PDU Transfers] 
LE 


CHART 7-S: S-format LPDUs in LINK_RESETING State 


Stimuli P: V: Action(s) CPDU Transfers] 
CRI ENTERS 
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m | x 
ayo 
m | x= 
Om | 
a | © 
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New State 


LINK_OPENING 
LINK CLOSED 


LINK_RECOVERY 


New State 


New State 
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CHART 7-U: U-format LPDUs in LINK_RESETING State 


Stimuli P: V: ALT] Action(s) [PDU Transfers] New State 
IH, Vi=Nul, TTl, ITi CLUA'] LINK_CLOSED 


Pum IH, VizNul, TTL, ITi LINK CLOSED 
PR 


L | IH, Vi=NUL, TT1, ITi, Ct=0, Pr=R LINK_RECOVERY 
LXC 


IP_(RE) 


K.8.2.8 LINK_RECOVERY State 


CHART 8-E: EVENTS in LINK_RECOVERY State 


: aaniON 
ViEL, TTi, ITL, Ct=0 | [LSM?3| LINK_OPENING | 
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CHART 8-I: I-Format LPDUs tn LINK_RECOVERY State 


Stimuli P: V: ALT] Actions) [PDU Transfers] 


CHART 8-S: S-format LPDUs in LINK_RECOVERY State 


CPDU Transfers] 


CHART 8&—-U: U-format LPDUs in LINK_RECOVERY State 
Stimuli P: V: ALT! Action(s) [PDU Transfers] 


LDM | IH, TTl, ITi 
LPR IH, Pr=R, TT1y ITi 
LXR IP 

“LTe IP 


K.8.3 Basic Procedure Definitions 


K.8.3.1 Acknowledgment 


New State 
LINK CLOSED 


New State 


New State 
LINK_RESETING 
LINK_CLOSED 


LINK_CLOSED 


CHART A: Procedure for the ELLC Acknowledgment Processing 


Stimuli P: V: ALT Action(s) (Frame Transfers] 
| a<Nr<Vs Va=Nr, RTI 
=Vs Va=Nr, TT1, ITi 
ELSE | 
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K.8.3.2 Limit 


CHART L: Procedure for the ELLC Limit Processing 


Stimuli P: V: ALT] ActionCs) [Frame Transfers] New State 


Ct="Ctt1" then 
Ct=LN2 ITH, TT1, IT 


ELSE 


K.8.3.3 Rejection 


CHART R: Procedure for the ELLC Rejection Processing 


Stimuli P: WV: ALT] Action(s) [Frame Transfers] 
a<Nr<Vs Va=Nr, RT1 
=Vs | Va=Vs=Nr, TTL, ITi OO 
ELSE Vs=Nr SO eee 


K.8.3.4 Link Test 


CHART T: Procedure for the Link_Test Processing 


Stimuli P: V: ALT] Action(s) [Frame Transfers] | New State 


ctxttNul Pt=I, TTi, RT1, Ct=0 CLTC+J| CHECKPOINTING 


c+xNul+t0d IH, Pt=Nul 
ct+xNulttIiIo IH, Pt=I 
ELSE 


K.8.3.5 Exchange Identification 


ct+ttxNul Px=I, TT1> RT1; Ct=0 


cttNul+x0O IH, Px=Nul 


ct+ttNul+xI0 
ELSE 
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